need design advice for distributed .NET application

[matman13]

I am a programmer with 10 years of experience, primarily with C++. I have absolutely NO experience with the .NET framework.

I am working on a brand new application in my spare time, and I want to embrace the .NET framework. I have a few questions and would appreciate any and all advice that comes my way!

1. What version of the framework is recommended? 1.1 or 2.0? Why?

2. With C++ experience, is C# the easier route or should I jump into VB.NET? I've worked with VB in the past, but my understanding is that VB fundamentally changed with VB.NET.

3. Garbage collection. As a C++ programmer, the idea of letting the system collect my unused memory bothers me. I'm all in favor of it as long as it does it smartly. Is it possible to control WHEN garbage collection occurs, or is that completely up to the system?

4. My application will have a countdown timer managed by a single application instance (is this is same as a .NET AppDomain?) that will update all other application instances on the network as the timer progresses. In my C++ experience, I have used a multicast socket to accomplish this where the server application sends a single UDP packet to the multicast IP address and all the client applications connected to that multicast IP address receive and process the packet "simultaneously." How would I BEST accomplish this in the .NET framework? Should I continue to use multicast sockets in the System.Net.Sockets namespace or should I go with Web Services or .NET Remoting? What is the rationale for choosing any of these options?

Thanks in advance. I really appreciate any advice that you guys (and gals) can give me.

 

[B00gyeMan]

1. Usually the latest version since there are bug-fixes and performance improvements of the 2.0 over 1.1 (the list is quite long).

2. C# is the easier route. There are some similarities between C++ and C# and to modify a famous quote ... "VB.NET is for the weak and timid!"

3. It is perfectly possible to force garbage collection (of all generations or only a specific one, it's your choice), but it is generally recommended to let the GC do its regular job since it does it pretty good. However, if you find yourself unsatisfied with the GC, and with respect to the generics introduced in .NET version 2.0 I am quite sure you can implement some sort of "smart pointer" in C# and use it to get rid of the unwanted allocated memory as you would do in C++ with a regular smart pointer. However, before you take any action, I strongly recommend you to read some docs. and to experiment.

4. This is mostly at your convenience. You can use multicast sockets or .NET Remoting (remember DCOM? ) With .NET Remoting you can easily make sure the timer message reached its destination (each remote app will acknowledge the message) but you must connect to each and every machine which runs the app, instantiate a specific object (yours, of course) which handles the message and give it the message. An inconvenient of this is that if a machine is down, you must wait for the connection timeout to elapse in order to proceed to the next machine (this issue could be solved using asynchronous delegates or OneWay delegates). Using multicast sockets you fire the message away and do not care if a machine is or is not running. There is much to discuss here, .NET Remoting can give you more control and you can easily extend the functionality, multicast sockets have their own advantages. If you have any specific question, fire away !


Ahhh, back to my

 

[matman13]

Thanks so much, B00gyeMan!

Do you have a C# book that you would recommend? I probably don't need a language book, but a somewhat more advanced book. But if there's a quick reference book of C# syntax, that might be nice to have.

Again, I greatly appreciate it.

 

[chiph]

1. What version of the framework is recommended? 1.1 or 2.0? Why?

Use 2.0 (VS.NET 2005) not only because it's the latest, but because it has generics, which make your life a lot easier when managing collections of stuff.

2. With C++ experience, is C# the easier route or should I jump into VB.NET? I've worked with VB in the past, but my understanding is that VB fundamentally changed with VB.NET.

Use C# because the syntax will be more familiar to you. But remember that the language is only about 5% of your learning curve -- the other 95% is in the framework and it's thousands of classes. Whenever you get to a point where you're saying "Well, it's time to write another {x}", look in the framework first. Some C++ programmers I know wrote their own XML parser, never even looking in the System.Xml namespace that would have saved them 3 weeks of effort.

3. Garbage collection. As a C++ programmer, the idea of letting the system collect my unused memory bothers me. I'm all in favor of it as long as it does it smartly. Is it possible to control WHEN garbage collection occurs, or is that completely up to the system?

Don't worry about it. All you need to worry about is implementing the IDisposable interface where you have unmanaged resources. And the easiest way to find out that is to run FxCop (available on the GotDotNet website) against your assemblies. It'll tell you.

Other than that, you really don't have to do anything. The garbage collector is really very good.

4. My application will have a countdown timer managed by a single application instance (is this is same as a .NET AppDomain?) that will update all other application instances on the network as the timer progresses. In my C++ experience, I have used a multicast socket to accomplish this where the server application sends a single UDP packet to the multicast IP address and all the client applications connected to that multicast IP address receive and process the packet "simultaneously." How would I BEST accomplish this in the .NET framework? Should I continue to use multicast sockets in the System.Net.Sockets namespace or should I go with Web Services or .NET Remoting? What is the rationale for choosing any of these options?

I would stick with multicast sockets because you're already familiar with them, and they're high performance.

In your socket programming, make an effort to use asynchronous sockets. And try not to use Thread.Sleep() or Thread.Abort(), as those will cause you problems (the first is a sign you don't have your inter-thread communications set up right, the second is just bad news).

And forget you ever learned about pointers. In .net, they're just reference objects.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[matman13]

Thanks, chiph.

1. Do I need Visual Studio 2005 to use the .NET Framework 2.0? I've got a full version of Visual Studio 2003, and I was under the impression that 2.0 .NET was simply a download and VS 2003 would accommodate it. Is that not the case?

2. I can already tell that my learning curve is going to be at least the same as for the Win32 API. I'm still finding functions in the API that I wrote functions for.

3. Typically, I don't go optimizing until everything is really close to done and I can get a better idea of where the bottlenecks are. Thanks for the advice.

4. My socket programming is strictly async sockets, i.e., non-blocking sockets. In C++, I would put the socket in a separate thread and bind a read event to the socket so that the thread would wake up and process the message when it was received. This has worked well for me, and I plan to continue that approach unless I find that .NET Remoting makes more sense for my application.

Thanks again. Do you have a C# book that you'd recommend?

 

[JurkMonkey]

Download C# Express from MS directly, its free and works quite well.

 

[Guru7777]

I don't think you can ever go wrong with any of Andrew Troelsen's books.

For 2.0, here is his latest book on Amazon.

http://www.amazon.com/gp/product/15...103-8896097-2718258?s=books&v=glance&n=283155

----------------------------------------

TWljcm8kb2Z0J3MgIzEgRmFuIQ==

 

[chiph]

1. Do I need Visual Studio 2005 to use the .NET Framework 2.0? I've got a full version of Visual Studio 2003, and I was under the impression that 2.0 .NET was simply a download and VS 2003 would accommodate it. Is that not the case?

If you want to use VS as your IDE, yes you do need 2005 to work with v2.0 of the framework. But you can always use Notepad and the CSC command-line compiler, or one of the third-party IDEs.

2. I can already tell that my learning curve is going to be at least the same as for the Win32 API. I'm still finding functions in the API that I wrote functions for.

Easily!

4. My socket programming is strictly async sockets, i.e., non-blocking sockets. In C++, I would put the socket in a separate thread and bind a read event to the socket so that the thread would wake up and process the message when it was received. This has worked well for me, and I plan to continue that approach unless I find that .NET Remoting makes more sense for my application.

In .net, you create a callback, and it passes you an object that realizes IAsyncResult. You can jam your own object in there (much like you did in C++) to pass state info to your receive method.

I don't really have a book to recommend, but you might try O'Reilly's Programming .NET Components by Juval Lowy (has a hermit crab on the cover). Several other devs here have it and like it.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first