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"

Alaric_ wrote: Vendor: Are you trying to insult my intelligence? No, I wasn't trying. :) Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

My general rule of software development: "Design should be top-down, but implementation should be bottom-up." So I agree that code-first is wrong, but I don't agree with your stated reasons. Of course, middle-first is even worse. I have worked at only two places where there were proper DBAs who controlled the database and all the developers could do was ask for additions and changes, I couldn't make the changes myself. On all other jobs, including now, I have had full control of everything myself top-to-bottom and that's how I like it.

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"

Figured it out. never mind. "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"

For completeness' sake, I thought I'd provide some additional clarification. Notice in the original code that I posted that in the GetUsers() method that calls the data connector, I did not await the Resolution of the promise. In fact, I didn't need to resolve that manually, so I changed the code that read like this... var connector = new Data.SqlServer(); Task.Factory.StartNew(() => { source.SetResult(connector.GetUsersSync()); }); return await task; to instead read like: DataConnector connector = new DataConnector(); return connector.GetUsers(); and then, to keep the async task from "completing before another async task could complete", I had to await the call to the data connector DataConnector connector = new DataConnector(); return await connector.GetUsers(); It was really easy once I was able to spot it. I just skipped over the StartNew(() call every time I was analyzing; took way too many looks to notice that it was not executing asynchronously. "I need build Skynet. Plz send code"

Just as I said.

This is by design, as shown by this quote from the C# spec: "User-defined conversions are not allowed to convert from or to interface-types. In particular, this restriction ensures that no user-defined transformations occur when converting to an interface-type, and that a conversion to an interface-type succeeds only if the object being converted actually implements the specified interface-type". (source[^]). I don't really understand why you can't cast from an interface, but there you have it. Having something that looks like a cast that actually switches to a completely different COM service is probably a bad thing anyway, though. When the conversion is so simple I recommend you just use 'new ExcelWorksheet(...)' and 'worksheet._worksheet' inline (well okay that last one should probably use a read property not the field directly).

I tend to think that they're just as good an idea as any. If you don't need to subtype the existing class, you don't need to change the way it performs its existing behavior, there's no composition model in place but need to be able to optionally rearrange the way the custom object wraps around a structurally subtyped object, I say "sure." "I need build Skynet. Plz send code"

Thanks, Mark. "I need build Skynet. Plz send code"

Ok...another mental block: I can read the rows in the sheet, I can access the cells from the row via an OleDbDataReader ...but how do I hook directly into a row in the Excel spreadsheet to update it once I have my update record crafted? using (OleDbCommand command = connection.CreateCommand()) { int idx = 0; command.CommandText = string.Format("select * from [{0}$]", "Report_12251104"); using (OleDbDataReader reader = command.ExecuteReader()) { while (reader.Read()) { string foo = reader[0].ToString(); string newcolumn = foo.Substring(foo.IndexOf(":") + 1); object\[\] meta = new object\[reader.FieldCount\]; reader.GetValues(meta); List<object> list = meta.ToList(); list.Insert(2,newcolumn); } OleDbCommand update = connection.CreateCommand(); //I want update.CommandText = "update ??what exactly?? Can I use idx to id a row by number??"; update.ExecuteNonQuery(); idx++; } } "I need build Skynet. Plz send code"

btw, MS advised that the following should be correct: Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties='Excel 12.0 Xml;HDR=YES;Imex=1;ImportMixedTypes=Text;TypeGuessRows=0; "I need build Skynet. Plz send code"

if((property.PropertyType ==(typeof(long))) || ((property.PropertyType == (typeof(long?))))) { long converted; if(Int64.TryParse(data.ToString(), out converted)) property.SetValue(instance, converted, null); } Money "I need build Skynet. Plz send code"

Thank you very much for the documentation, but I had already referenced the materials at those links. My specific question was surrounding the command-line reference that I was making to my package after it had been deployed. ...at any rate, I found out what my problem was. I was attempting to reference the package with the FILE switch, but I had not deployed the package to the file system of the database server which I was attempting to reference (I had deployed it directly to the SQL Server instance) ...I still am unsure of how I would go about referencing the package from SQL Server directly, but I repeated my deployment, this time to the file system, and adjusted my reference to the location on the file system, and the package was able to be loaded at run-time. just fyi...anyone referencing a package with the "FILE" switch, make sure your package is deployed to the file system lol ...it'll save you a night's sleep. "I need build Skynet. Plz send code"

I found an answer to my question. I created a stored procedure that accepts the GUID as a parameter and within the proc, I (create, add, and kick off) a job that executes the SSIS package as its only step, passing the GUID into the command line args of the command property of sp_add_jobstep. Right now, the only thing in my way is that the server was restarted last night and the Job Agent wasn't part of the restart....so I'm waiting for server support to get back from lunch so that I can test out my implementation. If anyone has any questions about my approach, I'd be more than happy to share. "I need build Skynet. Plz send code"

Congratulations! :-D Jack of all trades ~ Master of none.

Correct, None, software people don't deal with hardware. Q: How many hardware engineers does it take to change a light bulb? A: None, call the engineering tech. Q: How many engineering technicians does it take to change a light bulb? A: None, that's a facility maintenance problem. Q: How many Facilities people does it take to change a light bulb? A: Fifteen: 1: Facility Maintenance Technician - Comes out to inspect the light bulb. 2: Environmental Engineer - Must specify a RoHS replacement. 3: Configuration Manager - Must determine the proper LED replacement. 4: Procurement Specialist - Must source the spec'd replacement. 5: Purchaser - Must order the replacement. You didn't think it would be in stock did you? 6: Receiver - Must verify the correct part came in. 7: Job Control - Gotta have the job number. 8: Maintenance Tech (finally!!!) - to replace the light bulb. 9: QA - to inspect the job. 10-14: Fire department - To put out the fire that the 100W LED light started. 15: Accountant - to bill all the costs of the building replacement (with all new LED lighting) back to the original software group. Did I miss anyone?