Did you ever set a breakpoint within BackgroundWorker execution (worker thread), hit it and then application would stall. It is certainly a strange behavior.
Apparently the problem happens because debugger calls into ToString() of the BackgroundWorker's host (which is usual a Form derived class) and this call doesn't happen in the same thread as host was created (remember, never touch UI controls from non-creation threads). This situation yields unpredictable results, normally application just doesn't respond anymore. The cause and the workarounds to this annoyance is described in this blog post. Basically you have three possibilities:
- No more calls into ToString()
- Disable func eval entirely (ouch)
- Avoid the problem
I choose to go with the point 1. and it works for me. Point 2 is the worst choice.
I hope that debugger folks will do something regarding this issue in the future as it makes you wonder what is going on until you find the description.
There are two things you have to know:
- don't do a simple upgrade. Rather uninstall previous version, clean GAC, Program Files and Common Files and do a fresh install. There seems to be an issue in previous installer. No big deal.
- The other issue is with designer. To be more precise, the designer of inherited forms. If you happen to get an exception at design time when opening a derived form don't fear another Visual Inheritance drama. Just follow these steps (note: I am not sure which step is required and which is not (I guess removing and re-adding references is not) as I just did them all):
- delete license.licx file
- remove references to all devexpress assemblies and re-add them
- close IDE
- open IDE and rebuild the solution
- open the form again and you shouldn't have any problems
Since I've upgraded my CS blog engine to 2.0 beta2 I had problems posting - IOW I couldn't post anymore. Thus I've rolled back to CS 1.1 for the time being so you can read more news from RightHand. Isn't Virtual Server just beautiful for this kind of hacks.
If you do serious development then you probably know that you have to deliver executables to your client or to a tester occasionally or perhaps every day, every week, etc. When the project grows it becomes more and more annoying and error prone building it, including all files, copying it to the right folder, notifying the person(s), etc - you probably know all that already. That's why one has to use a proper build tool instead of manually hassle all that steps.
That's why I decided to try FinalBuilder 4 for my VS.NET 2003/.net 1.1 application. Build processes for this application includes building two different configurations and a third, obfuscated version (using Dotfuscator), creating help files (NDoc), an XML schema for certain objects, including some additional files and copy everything to a target folder - more than enough possibilities for a human error.
Creating a build automation rules out the human error and with FinalBuilder 4 it took me only an hour or so - it supports myriad of build actions (against various 3rd party products) out of the box, basically almost everything I needed (except for the XSD thing). All of the actions have an UI designer so setting them properly is just a matter of few clicks and key presses – easy and straightforward. And if it happens that an action you need is missing it is very easy to develop your own using your favorite development technology (COM, scripting, .net). I’ll write more about developing custom actions in the future.
The bottom line is that FinalBuilder 4 proved very useful and valuable tool for me. Setting up a new build process (without my prior knowledge of FB) was very easy and fast and all the actions I need were already there. I guess I could achieve similar automation using free NAnt tool but it would certainly took me more time and I guess NAnt doesn’t have all of the actions FB4 provides out of the box.
I saw Andrej's post on the new Infragistics Netadvantage Vol. 3 for CLR 2.0 (VS2005/.net 2.0 that is) and went investigating what's up. As you remember weird things are going on with VS 2005's visual inheritance support. Fortunately, Developer Express managed to workaround these new VI barriers imposed by Microsoft. The same can't be said for Infragistics though. After the brief investigation I found that NetAdvantage's UltraGrid (haven't tested other complex controls) has big issues with VI and you should be very careful when using it in VI scenarios. It doesn't lockdown entirely as MS' DataGridView does (collection properties are locked down as usual) it just doesn't implement VI properly (note that I don't have any experience with previous NetAdvantage versions).
For example, I put an UltraGrid on the form, set its modifier to protected, add a column and inherit such form. Now, the column appears properly on the derived form but just as long as you don't change anything on the base form. The reason is simple: UltraGrid rewrites columns on the derived form instead of inheriting them - that is completely useless behavior for VI. On the bright side I can say that UltraGrid isn't just disabled on derived forms.
If you are learning managed DirectX you'll certainly appreciate nice tutorials, such as these (found them via Z Buffer).
UPDATE: Looks like both mentioned links are not accessible anymore.