bool currentConfirmValue = attendee.IsConfirmed.HasValue ? (bool)attendee.IsConfirmed : false; //bool? to bool, treat null as false
When moving to a new implementation of Active Directory – an old piece of code that had been working for ages stopped. This was around using the “System.DirectoryServices.AccountManagement” namespace specifically adding a user to an AD Group now suddenly returned this error: “”Information about the domain could not be retrieved (1355)”.
Why? Because the server doing the provisioning was not joining to the new AD domain. Since joining was not an option – I had to find a workaround for the code. Thank you for martijnh1 for this excellent post on a decent workaround, relying on the old System.DirectoryServices library.
Most CRUD WebAPI’s include a POST, a GET, a PUSH and a DELETE.
Recently when trying to call a POST in my WebAPI I got this error message:
“Multiple actions were found that match the request”
Even though I clearly had only one POST, one GET, one PUSH and one DELETE. I couldn’t understand why it was telling me multiple actions were matched against my request.
Turns out, the problem was I had another public method defined in the WebAPI controller. This was actually just called by my normal POST operation – but because it was defined as public the WebAPI’s routing gets confused. Changing the method’s identifier to internal resolved the problem.
The lesson learned here is, unless it’s a POST, GET, PUSH, DELETE or some other valid public facing WebAPI action – make sure you don’t use the public identifier for any other methods you might have in the controller.
I was recently faced with the problem of writing an application responsible for uploading files consisting of several Gigabytes over the internet and we decided to integrate with Microsoft’s BITS technology (Background Intelligent Transfer Service). That’s because there’s a 2GB limit in terms of what you can send over http, so you need some technology to slice up a file in smaller bits and transmit each of these bits and then re-assemble them server side. For this sort of thing, BITS is perfect. Coincidentally it’s the same technology that Microsoft uses to push updates to your machine. There is a .NET wrapper that you can use https://sharpbits.codeplex.com/ which makes integration with BITS a lot simpler.
One frustration in dealing with BITS as a developer though – is that while you’re debugging your application, you often end up with BITS Jobs in a “corrupt” state – they’re neither active nor paused nor cancelled. Getting rid of these corrupt jobs can be an irritation as not even rebooting your machine will get rid of them!
There are three things you can try.
1. Clear out via command prompt
The easiest thing is to run your standard command prompt as an administrator and run this command:
bitsadmin /reset /allusers
That should do it. If that doesn’t work, however,
2. Clear out via Powershell
try firing the next commands from Powershell:
Get-bitstransfer –allusers | remove-bitstransfer
Most of the time, either one of the two options should do the trick. But at times, a corrupt job will be stubborn and you need to take stronger measures to remove the sucker. In which case I recommend the following:
3. Hard Delete
Microsoft stores BITS jobs here:
1. Stop BITS service from your windows services in control panel
2. Delete all the .DAT files from the location above.
3. Start your BITS service again.
An on-going pesky problem when reading from a database in .NET either via a DataReader or DataSet or some other means is having to cast to a data type, and when you get back a type of DBNull you always require some code to handle it. What I mean is, if I have a variable of type Int? doing this
MyIntVariable = (int)DataReader[“MyColumn”];
will error out if “MyColumn” comes back with a NULL value. It’s always possible to write some code to handle it, but it’s nice to get it down to a simple one-liner. Luckily using a combination of the “as” keyword for our casting and the null coalescing operator (??) we can make it as simple and painless as possible in one line of code.
//handle possible null value
MyIntVariable = DataReader[“MyColumn”] as int? ?? null;
Historically passing a collection as a stored procedure parameter has always been hard. Out of habit since the Sql Server 2005 days I typically passed my collection as a structured piece of XML, which I would then interrogate on the SQL side. This is a very painful and cumbersome approach, and when I recently encountered the problem again I wondered whether there was not perhaps a more elegant way of doing this. Turns out since Sql Server 2008, you can create a user defined type and then pass your collection as a DataTable from .NET. This is much easier and far more streamlined. Here is a great post on that very subject
3 good ways:
1. Unit testing – consuming service via c#
2. Via the Fiddler tool
3. Via a Chrome Extension called “REST Console”