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.

The whole point of using asynchronous methods is so that you don't block. And a good way to tell if you�re doing multithreading programming wrong is if your code contains any calls to Sleep(). I do not quite understand what your problem is. Why can�t you just use the event?

I use nDepend in addition to FxCop. Check it out. http://www.ndepend.com

lol, or you could always try brainfvck.

Object Browser is your friend. Search for the string "Memory" and you'll find System.Diagnostics.Process

Yup, all the same.

Imports System.Text.RegularExpressions ... ... Dim partPattern As New Regex("^\\d+", RegexOptions.Compiled) ... Integer.TryParse(partPattern.Match(partId).Value, partNumber)

RegEx - "\d+"

Yes, thankfully this is fixed in VB.NET Really dumb design in the first place, but then again that "performance hit" is pretty inconsequential. The lines: Dim o As New c Dim o As c = New c are the same.

Memory allocation takes place in constant time in .NET (which is why it's possible to write apps that are faster than C++). Garbage collection moves all allocated memory to the front so that new memory can be allocated instantly since all free space is in one solid block.

Or better yet you can treat C# like an object oriented language and not use an object array. :p