IngisKahn

3 things: Add stateful objects to your queue, not threads. Use lock/SyncLock to avoid race conditions Consider using a thread pool if you have more threads than cores or number of threads waiting on IO.

Stress testing through the debugger? That doesn't sound right. Also exceptions are generally a bad thing. Why are you throwing so many? Calling Sleep is always a bad thing. Calling Thread.Abort from another thread is always a bad thing. Use the provided thread syncronization objects.

Ghostdoc: Wow, great tool.

That just depends on how much you want to "protect". A function or two's worth would be trivial.

I'm not sure what you mean. Your encrypted DLL would be implementing a public interface. One cast and you're back in buisness.

There are many options you can take. Your best bet is an obfuscator. Obfuscated code is harder to reverse than native code. Of course, that costs money. A cheap and easy way (at least where a single run thru Reflector won't give you the source) would be to encrypt a dll that implements some interface defined in another assembly preferably. You can then at runtime decrypt this dll to memory and load it (Assembly.Load). They’ll have to put some effort into getting the code now. Remember too that what Reflector gives you is only its interpretation of the source code. A lot of the branching and looping code is messed up, you lose local variable names, and all comments go out the window.

Then your DLLs would be the first things I reverse. :p The answer to your question depends on exactly what your goal is in "protecting" your code. IOW, why do you want to stop people from using reflector on it?

new System.Diagnostics.StackFrame().GetMethod().Name

Do you mean contains or ends with? The $ at then end means ends with. .+(?:(?:\.com)|(?:\.co\.uk)|(?:\.info))$

User clicks menu. New form appears. Controls are populated/enabled as data becomes available. (Setting the form caption to "X - Loading" in the interim is an option.) The only difference between this and your method is that the user is not faced with a seemingly broken application while it is loading. BTW, MS themselves said that they have had bad UI thread practices in the past.

You say the code needs to block, if you're on a UI thread then that's a no-no. It's as simple as that. You can't have any functions in your UI thread that wait for anything. Do events really make for ugly code? Calling BeginX methods, doing stuff, then calling EndX methods kills the whole idea (especially on single core systems) of concurrency.

Or just use the super handy BackgroundWorker class.

The Lookups object would not load your form, your form would handle an event raised by your Lookups object.

Use your event to finish loading and enable your form. The UI thread should never block; there's nothing worse than an unresponsive UI.

I would run setup to install or repair the debugger. :p Installing VS2k5 shouldn't affect it, but Office 2k3 does.