In C++, it's possible to write: if (x = 0) when you mean to write if (x == 0) Because of that, some developers invert the order of what they write, as: if (0 = x) is illegal, while if (0 == x) is legal. This is not a problem in C#, where if (x = 0) is prohibited.

http://blogs.msdn.com/ericgu/archive/2004/04/01/105644.aspx

There are a few examples of that around (SharpReader is a good example of a non-programming-oriented program), but it is true that the size and hassle of downloading the CLR makes it less convenient for the end user. And there is inertia, both in programmers and in their existing code. On the other hand, it's generally much easier to write a windows program in C# than it was in C++.

Genghis might help: http://www.sellsbrothers.com/tools/genghis/

Inside Windows NT is a good overall reference: http://www.amazon.com/exec/obidos/tg/detail/-/1572316772/002-5183796-2704014?v=glance

I think I would write this as: @"^\d{5}(\.\d{2})?$" Well, actually, I'd write it as: @"^ \d{5} # 5 digits ( \. # decimal point \d{2} # 2 digits )? # match zero or one time " and then use RegexOptions.IgnorePatternWhitespace (it wasn't clear to me if you meant "only 5 digits" or "from 1 to 5 digits" in your description, so you might need to change the first part.

[Flags] isn't really a compiler thing. It's used by object browsers to tell people what kind of enumeration it is, and Enum.ToString() bases its behavior on whether [Flags] is present.

[Flags] is merely an attribute that's put on enums - it doesn't change the compiler behavior. We don't automatically switch to powers of two because people often want to define combinations of flags, and what was going on would be much less clear if that was the case. Ditto for looking at the numeric values someplace and having to translate back to the identifiers.

Two options: 1) Compile it into a DLL. 2) Write a wrapper using Managed C++.

If you run fuslogvw, you can see what fusion is doing when it's trying to load your assembly. That usually helps me.

When you specify sharing, you need to match the sharing that the file was opened with. In my tests, using FileShare.ReadWrite worked.

Try using: File myFile = File.Open(...) using the version that takes a FileShare enumeration, and then create the FileStream from that.

A couple of comments: 1) The .NET image classes are a thin layer on top of unmanaged GDI+. You should definitely call Dispose() on them to free that data. 2) Look at the performance counters for .NET to see how much memory you are really using. Task manager is not a good indication of how much is really being used. 3) In general, you should try to avoid calling GC.Collect(). You may, however, want to call it and call GC.WaitForPendingFinalizers() for testing purposes. That will ensure that all the memory is reclaimed before you look at memory usage. You might also want to try running the allocation profiler - it will give you a better idea of what your application is doing with memory. http://www.gotdotnet.com/community/usersamples/Default.aspx?query=allocation profiler

Joel, You will definitely want to break it into chunks, and, with that much data, you will probably want to put some error-recovery around it to restart the download if something bad happens. I suggest include some sort of identifier (ie filename) and the chunk number with each chunk. Chunking also allows the remote app to display some sort of progress bar as the data comes across, which tends to be pretty useful.

I've used the approach that you're thinking of with some reasonable success (but remember that I'm a Microsoft PM, and therefore, by definition, never write any *real code). Having it central has made things quite a bit easier, and allowed me to centralize things like caching. My personal preference is not to use DataAdapters and DataSets when I take this approach, and write routines that look like: public List GetValues (string selectStatement) { OleDbCommand select = new OleDbCommand (selectStatement, connection); List list = new List (); OleDbDataReader reader = select.ExecuteReader (); while (reader.Read ()) { list.Add ((T)reader[0]); } return list; } This is a version using Whidbey generics, but you get the idea. For me, this is much simpler to code and understand than using the built-in data support in VS. Of course, I spent 3 years working for a database company (SQL is my friend...), so your mileage may vary.

I should have noted that if you don't have Word, you can download the Word Viewer from: http://www.microsoft.com/downloads/details.aspx?FamilyID=9BBB9E60-E4F3-436D-A5A7-DA0E5431E5C1&displaylang=EN

I think the anonymous delegates are somewhat a matter of taste, and should be used wisely ("If swelling persists, contact a professional programming practitioner immediately"...) There is the opportunity to make your code much more ugly, but there are also cases where you can make it much more local. If you want to be able to have a named iterator that can take some code, or you want to specify the MatchEvaluator for a Regex.Replace(), you can make your code more understandable (probably...) with an anonymous delegate. But I don't view them as a replacement for standard delegates.

The specs for C# 2.0 are now available on MSDN at http://msdn.microsoft.com/vcsharp/team/language/default.aspx There is a discussion forum for the language on the same page. Eric Gunnerson Visual C# Compiler PM

The tradeoff really depends on what you're doing. If you're going to be touching all the data often, loading it all in can be good. If you only touch a fraction of the data, then loading it is probably bad. You may want to look at your database structure to see if you can make it more effective.

Can you give me an example