Awww...son of a crap. No idea how this happened, but Jenkins was generating falsely succeeding builds. This is an "old new" ci server (early in the config but I haven't visited it in 8 or 9 months) I had installed the MSBuild plug in but hadn't handled the config bug (you have to configure the job with the folder specified in the plug-in sans executable, but you have to go back and edit the value to point the agent to the actual executable) I also had forgotten to specify my MSBuild Agent in the project's job, but the build was succeeding on checkin. I have no idea how Jenkins was using MSBuild to build when I hadn't pointed the MSBuild plugin to the executable, but fixing this fixed the problem.

C:/server.ci/baz.inga/baz.inga.resources.sln
/t:build /p:PlatformTarget=x86 /p:Configuration=Release

...and everything builds just fine. When did Jenkins start building MSBuild straight out of the box? ...In fact, when did it start checking out of a git repository with no polling trigger? These were what really confused me.

"I need build Skynet. Plz send code"

I have a solution with several projects. In VS, I have my host project set as startup for Debugging in [IIS Express], but I want to make sure that when I check into my git repository and a build is triggered in Jenkins, it will always build my test project. Is there something I can add to the MSBuild script in my sln file to instruct that I *always* want the test assembly to be built? Something that I'm noticing is that if I change the startup project in Visual Studio and commit the sln file, whenever an automated build triggers in Jenkins, it only builds the "current" project. Any idea how to override this behavior? I want the Jenkins build to build the same artifacts every time and I don't want tinkering in VS to impact the automated build (unless their change actually breaks it) [Edit] ...the gist of this is that I have my specs.csproj file set up with

bin\Debug\

for a Debug build and

bin\Release

for a Release build. But the automated build does not output anything to the bin folder for this project. If I trigger a build of the project manually in VS, everything works as expected.

"I need build Skynet. Plz send code"

Me: I'm having some trouble understanding your data model. The Foo in this table doesn't match the Foo in that table and there are bidirectional, implicit relationships between two other tables that have no referential integrity. The "BarId" on "EntityA" seems to match with "BarId" on "EntityB" but there is a "Bazinga" on "EntityA" that matches a different "EntityB" where "EntityA.BarId != EntityB.BarId" These conflicts are making it very difficult to trust your schema and it is also very difficult to know which version of the database's facts represent our real business data. Vendor: I don't see any issue. It appears you just have not been provided with clear details on how our data model works. You see, three plus five equals threeve. Me: Beg pardon? Vendor: Three plus five equals threeve. This is simple math. Me: Three plus five is eight. There's no such thing as threeve. Vendor: Are you trying to insult my intelligence? Me: ...I don't think that's how math works. [later] Bean Counter: [Vendor] just informed me that you didn't know that three plus five is threeve. I thought you were an expert and I hear you can't even do simple math. https://en.wikipedia.org/wiki/threeve[^] Just make it work! Me: ...

"I need build Skynet. Plz send code"

So this is weird. I'm trying to manually fiddle with a property of my MS_RequestContext during Controller Activation inside my WebApi's CompositionRoot. my Create method receives a System.Net.Http.HttpRequestMessage argument. I can drill down request to grab

request.Properties["MS_RequestContext"]

Properties is a

dictionary

That object will be an OwinHttpRequestContext at runtime. But whenever I attempt to cast, so that I can access the properties on the RequestContext, I get a naughty-gram from Visual Studio

(request.Properties["MS_RequestContext"] as OwinHttpRequestContext).Request.Properties;

The error that comes back is:

The type or namespace 'OwinHttpRequestContext' could not be found (are you missing a using directive or an assembly reference?)

Well...OwinHttpRequestContext lives inside the System.Web.Http.Owin namespace. My references are all set up. I even have added a using statement for good measure. So the crazy part is that if I remove my code that attempts to directly reference request.Properties, but instead set a breakpoint inside my Create method, I can -through a watch- execute

(request.Properties["MS_RequestContext"] as System.Web.Http.Owin.OwinHttpRequestContext).Request.Properties

without issue. I can confirm that I have no problem modifying the properties at runtime through the immediate window. Why am I not able to perform this same cast at build time? I've inspected the

HttpContext.Current.GetOwinContext()

for access to the property that I need to manipulate, but it's not available on IOwinContext.

"I need build Skynet. Plz send code"

Brady Kelly wrote:

You don't understand Code Based modelling. Then, you have incompetent developers. That's now three problems, the third being you have no competent DB developers/DBAs.

There's really very little to understand. Code based modeling came about as a way to "easily" maintain an implementation history of a database, which can be done just as effectively by other methods without castrating your data model.

"I need build Skynet. Plz send code"

Bergholt Stuttley Johnson wrote:

yet by your own argument you should not be let near the DB

How so? You have misunderstood my argument(more of a rant than an actual argument) if you feel I said that.

Bergholt Stuttley Johnson wrote:

sorry but you have got to remember that sometimes DB is basically a bucket to store info used by the application,

Implementation detail. That's not to the application developer to decide. That's for the data modeler to decide, even if those are the same person.

Bergholt Stuttley Johnson wrote:

I have had system that missed delivery dates due to DB admins over engineering simple dbs so the problem can be from both directions

Over engineering is an orthogonal concern. If you have a defined layer of Views, Stored Procedures, and Functions as your interface into the database, then a DBA should have full rein to normalize the physical tables any way they see fit, within project constraints.

Bergholt Stuttley Johnson wrote:

to write off a tool because you feel left out is not the answer

I never feel left out. Crappy Entity Framework implementations and Code First databases have generated a ton of work for me. It's just disheartening to have to explain to businesses that the green field developers that dropped in on them with industry jargon and "bleeding edge" tools royally ripped them off.

"I need build Skynet. Plz send code"

cjb110 wrote:

unless you're saying there's some limitation in EF code first?

It's limited by design by not only allowing but promoting the structure of application artifacts(and the context that was used to write them) to dictate the persistence model of a system. As with the DataSet, if you are developing a toy, it works great. If you're trying to do anything substantial, it falls flat on its face and costs you more than it helps you.

"I need build Skynet. Plz send code"

Bergholt Stuttley Johnson wrote:

Sounds like a DB admin rant. remember that some DB admins think that programmers are the spawn of the devil* and should not be let anywhere near the sacred databases

For the record, I'm an application architect and C# developer first. I'm also (I feel) a competent domain modeler, a competent relational data modeler, a competent "junior" database administrator, and a world class Service Nazi. And no, you absolutely aren't supposed to touch a database as an application developer. The relational model is an implementation detail. You can touch the database while wearing a data modeler's or a database administrator's hat, but not as an application developer. You will break shit.

"I need build Skynet. Plz send code"

...a really, really, really stupid idea. Let's pretend that EJB3 was a good idea. Let's double down on incompetent developers pretending they are passable data modelers. Let's double down on incompetent developers pretending they are database administrators. Let's double down on giving the application layers primacy over all others. Let's double down on incompetent developers resolving the Object Relational Impedance Mismatch by completely ignoring it. Let's double down on incompetent developers treating databases as little more than a bag for their crap. Guess who is up all night fixing someone else's quagmire.

"I need build Skynet. Plz send code"

Regarding elections, I tend to agree with George Carlin.

“I don't vote. Two reasons. First of all it's meaningless; this country was bought and sold a long time ago. The **** they shovel around every 4 years *pfff* doesn't mean a ****ing thing. Secondly, I believe if you vote, you have no right to complain. People like to twist that around – they say, 'If you don't vote, you have no right to complain', but where's the logic in that? If you vote and you elect dishonest, incompetent people into office who screw everything up, you are responsible for what they have done. You caused the problem; you voted them in; you have no right to complain. I, on the other hand, who did not vote, who in fact did not even leave the house on election day, am in no way responsible for what these people have done and have every right to complain about the mess you created that I had nothing to do with.”

There's no point in voting under this system. Both parties have taken for granted that they have the authority to steal anything they wish from whoever they wish; the R-Tards and the D-Bags just differ philosophically on what those stolen resources should be spent on. I want them to spend it on a guillotine and volunteer their own necks to test it.

"I need build Skynet. Plz send code"

RyanDev wrote:

Does that mean you can double-click a file to install an application you download off the internet?

They're waiting to see if the Internet is just another fad before committing themselves to the effort. I mean, how stupid would they look if they made it so that you could package an installable for their platform and distribute it across the internet if all these Interwebz machines are just going to be gathering dust in 3 years.

"I need build Skynet. Plz send code"

I always post third, read first THEN think second.

"I need build Skynet. Plz send code"

so...when the heck did nested object initializers become good form??? (Note that this seems to be the only way to interact with the Origins collection. Once the CorsOptions object is constructed, there is no direct access to the properties on the PolicyResolver)

CorsOptions cors = new CorsOptions
{
PolicyProvider = new CorsPolicyProvider
{
PolicyResolver = context =>
{
var policy = new CorsPolicy
{
AllowAnyOrigin = false,
AllowAnyHeader = true,
AllowAnyMethod = true,
SupportsCredentials = true
};

                    policy.Origins.Add("http://localhost");
                }
            }
        };
        app.UseCors(cors);

"I need build Skynet. Plz send code"

So, I've got an open question on so We're experiencing cors issues with signalR resources and I can't imagine that I'm the only one that has had to solve this problem. The "default", documented configuration settings for enabling cors with signalR are

public void Configuration(IAppBuilder app)
{
app.UseCors(CorsOptions.AllowAll);
app.MapSignalR();
}

but CorsOptions.AllowAll configures wildcard Access-Control-Allow-Origin and you cannot specify a wildcard value AND use withCredentials. So I'm investigating what it would take to create a custom Microsoft.Owin.Cors.CorsMiddleware or create a different CorsOptions setting. Does anyone have an example that replaces

app.UseCors(CorsOptions.AllowAll)

with

app.UseCors("CorsOptions with a CorsPolicy that doesn't specify wildcard origins")

"I need build Skynet. Plz send code"

Figured it out. never mind.

"I need build Skynet. Plz send code"

Ok..so create a table in SQL Server with a [varchar](50) primary key and insert 500,000 dummy rows into the table. Now, in SSMS, select all rows from that table and you will see results immediately display in the Results window while the query is still running. Opening an ADO.NET connection while awaiting an async reader will allow the thread to continue doing *different* work while the query runs, but I want to yield the results from my data layer to a UI layer as SQL Server prepares and marshals them. Does anyone have any working samples (technology agnostic) or any links they can direct me towards?

"I need build Skynet. Plz send code"

Awesome sauce...but I don't care about an FP Algorithm. I need your codes for Skynet. I know you're holding out on me. Send code to 69inGCh1pmunks@gmail.com. Thanks!

"I need build Skynet. Plz send code"

Any time you have an application send SQL to a database that identifies the data tables, you are doing it *so* wrong§. You should treat the data model as an implementation detail and the stored procedures and Table Valued Functions (if MSSQL) as your data services. It would be much, much nicer if the SQL Server team had followed through on their rhetoric that table valued parameters would be able to be OUTPUT parameters "in the next release of SQL Server" (which should have been 2008R2...that would allow the DataTransferObject to be registered directly with the DBMS) but an ADO.NET bridging layer that performs your data transfer into the application domain is *ridiculously simple* §...and that's why Entity Framework is pure, unadulterated evil; It's the ADO.NET DataSet 2.0

"I need build Skynet. Plz send code"

(see signature) SEND THE CODEZ NOWZ!!!!!

"I need build Skynet. Plz send code"

Member 9986689 wrote:

You can, however, use Process.Id to identify your runnung app.

The problem here is that the process I was spawning was a daemon, and there is a battery of instances of the daemon all with the same process name...so without some way to either specify the processId of the child or persist its processId before the parent process died, there would be no way to attach to the proper instance (and the instances were not interchangeable) I was able to work around this by adding a Configurator that attached the monitoring process to the daemon as it was being spawned. ...Being able to assign it an arbitrary ProcessID would have made the job easier and reduced the complexity of the implementation (not sure what justified the downvote of my original question)

"I need build Skynet. Plz send code"