There's a bug in both the 1.0 and 1.1 versions of the .NET frameworks that can cause web service calls to throw a WebException with HTTP error 400 Bad Request. This bug comes up when posting a more than 48 kilobytes of data to a web service protected by HTTP authentication. In my case, I was working on a WinForms client that uploads image files to a web service. The problem was hard to track down, but eventually I was able to find a workaround that works well enough until a fix comes out.
When using HTTP authentication for a web service, the proxy class generated by the Web Reference feature in VS or the wsdl.exe tool will make requests with no authentication header until the server responds with a 401 Unauthorized error. The 401 response lets the proxy class know which authentication mechanisms the server supports, such as Basic or Digest. If you're supplied the proxy class with a valid NetworkCredential, the proxy class will automatically retry the request using those credentials for one of the supported authentication mechanisms. This all happens transparently to the client application; you won't see that 401 unless you're packet sniffing.
The bug happens only on the first request to the server when the proxy class doesn't yet know which authentication mechanisms the server supports. Since the proxy class doesn't know which authentication mechanism to use, it sends the first request without authentication. IIS buffers the first 48 kilobytes of the request before it hands off to the ASP.NET handler and, when it does, ASP.NET refuses the request since it wasn't authenticated. Despite receiving a 401 Unauthorized error, the client's proxy class keeps sending data to the server which then causes IIS to send back a 400 Bad Request error. The 400 gets thrown as a WebException and the call fails.
Now for the workaround. If the first web service request your proxy class makes is going to be more than 48 kilobytes and the server is using HTTP authentication: Set the proxy class's Credentials property and set the PreAuthenticate property to true then call a no-op method or any other small method on your web service before the big request gets made. The small web service call will initially result in a 401 which will let the proxy class know which authentication mechanisms the server supports. With PreAuthenticate set to true, the proxy class won't make the same mistake twice and all subsequent requests will work fine with authentication happening transparently. This way you never have to worry about catching a WebException for the 400 or the 401 and the only thing you've wasted is a quick call to a no-op method on the web service -- much better than catching the 400 and sending the big request back to the server.
After going back and forth over which wireless router to get for the house, I finally settled on a Linksys WRT54G. Despite having slightly less range than some comparable models and being a bit more expensive, I decided Linksys would probably have the best overall quality. I was basically trying to avoid the multitude of problems we've had at work at the mercy of a Netgear router.
The first thing I did when I got the Linksys router was upgrade the firmware to the newest version... You can imagine how my faith in Linksys' quality was shaken by this screenshot :)
But other than that screen that appears to have been written by a non-English speaker, I've been very happy with the wireless router. Enough configurability even for my crazy network and I've had no problem at all surfing the Internet from the couch downstairs :)
Brad Abrams has a post called MessageBeep in the .NET Framework that shows how to trigger the Windows default sounds from C#.
Here's how to do it:
public enum MessageBeepType
{
Default = -1,
Ok = 0x00000000,
Error = 0x00000010,
Question = 0x00000020,
Warning = 0x00000030,
Information = 0x00000040,
}
[DllImport("user32.dll", SetLastError=true)]
public static extern bool MessageBeep(
MessageBeepType type
);
I have created an installer for CropMonkey 1.0, so all you have to do now is open the MSI file and it will be installed automatically. There are no differences between this version and the zip version I posted earlier, just download whichever one is easier for you. Have fun cropping your digital photos!
Click here to download the installer for CropMonkey.
Click here to see the original post for the CropMonkey 1.0 release.
CropMonkey is an application I've been working on for quickly and easily cropping digital photos to standard proportions. It lets you select a proportion such as 4x6 or Panoramic and resize a selection box that keeps that proportion. Once you're satisfied with how the photo looks you press the Crop button on the toolbar and save the cropped version of the photo.
Click here for a screenshot and click here to download CropMonkey. Note: You must have the .NET Framework 1.1 installed.
This is the first release and it contains the following features:
*Save as JPEG with variable quality level
*Save as Bitmap
*Unlimited undo/redo
*Copy cropped image to clipboard for pasting into other applications
*Easy to use interface
I really want some feedback if you find CropMonkey useful. If you have any feature suggestions or find any bugs, PLEASE let me know in the comments on this post.
If you've looked very closely at your compiled .NET assemblies, you've realized there's a lot of information readily available in the IL.. Tools like Anakrino and Lutz Roeder's Reflector allow anyone to decompile your assemblies into something very similar to your original code. If you want to protect your code, obfuscation is the solution.
Let me clear up one common misconception first: ngen does NOT protect your code, to be able to run ngen a user already has your original assembly! Ngen only generates a native image and installs it into the computer's native image cache so the assembly can load and execute more quickly.
A simple obfuscator will just rename all your symbols (classes, methods, variables, etc.) to gibberish strings that would make it very hard for someone to understand your code once decompiled. Smarter obfuscators will play tricks like inserting weird branches that don't ever get taken or change if statements into loops that only run once in the attempt to break decompilers and generally make your code such a mess that decompiling isn't worth the time it would take. Many obfuscators will also encrypt strings and remove unused code and metadata from the assembly.
I've used Dotfuscator Community Edition which is a free download and only does symbol renaming. A word to the wise: Take the 1.0 Framework and SDK out of your path and put 1.1 in your path before using Dotfuscator... Apparently Dotfuscator uses the ILDASM/ILASM utilities and the assembly attributes get corrupted when it uses the 1.0 versions of those utilities -- even when building 1.0 assemblies. Other than this fixable problem and the ugliest interface known to man, it works like a charm.
QNDObfuscator is an open source (Mozilla license) obfuscator that seems to do a better job with symbol renaming than Dotfuscator. In fact, decompiling with Reflector fails completely. I did run into a problem with the assembly attributes being corrupted... let me know if you have a solution to this problem. If you're not using anything like Application.ProductName which reads an assembly attribute then you have nothing to worry about.
Anyone have any other tips for protecting your code?
For anyone who's interested in the coming changes to weblog syndication formats, Rich Salz's article on xml.com is a good read. He does a good job going over the problems with RSS, the solutions presented in Necho, and how we get there from here.
A while back I was trying to debug an ASP.NET site and I needed to view the HTTP headers the server was sending. Even with the power of Google, I couldn't find a decent utility that would let me enter a url and view the response headers that came back. So, like any decent developer, I wrote a simple WinForms app that would do just what I needed.
It's called HttpGuillotine and I'm making it available in case anyone else might find it useful. Let me know (in the comments) if you do and if you have any suggestions for making it better. Download HttpGuillotine here. (Requires .NET framework 1.0 or higher)
Now that multiple versions of the .NET framework are available it's sometimes necessary to force an application to run under a different framework than it was built for. This is especially necessary when the application is loading assemblies at runtime.
NUnit is a great example of this. The downloadable binary version of NUnit was built for the 1.0 framework, but your application and unit tests may have been built under the 1.1 framework and, even worse, may be making use of 1.1-only features. If the have both the 1.0 and 1.1 frameworks installed, NUnit will start up using the 1.0 CLR and framework classes since that's what it was built for. Then when you try to run your tests they will be running (or crashing..) on the 1.0 framework even if they were built for 1.1! This happens because there can only be one version of the framework per process and since NUnit started using the 1.0 version, your tests have to use that version too.
If your application is built for 1.1 then it doesn't make sense to run all your unit tests on 1.0. If you're making use of 1.1-only features, then you have no choice but to test it on 1.1. The key is to force NUnit to run under the 1.1 framework by adding the following <supportedRuntime> option to the nunit-gui.exe.config file in NUnit's directory.
<?xml version ="1.0"?> <configuration> <startup> <supportedRuntime version="v1.1.4322" /> </startup> </configuration>Where the version is the exact version of the framework you want to force NUnit to run under.
I've found this to be a much cleaner solution than rebuilding NUnit and referencing that custom build of nunit-framework.dll from all my unit tests. For more information about targetting a specific version of the .NET framework take a look at this article on MSDN.