.NET or Win32
-
How many developers are starting a brand new large scale project using C#/NET? I was just curious. My company has stipulated that C++/MFC/ATL will be used for our new project. I personally think it is a mistake since we can wrap our legacy code in COM and use it in NET.
-
How many developers are starting a brand new large scale project using C#/NET? I was just curious. My company has stipulated that C++/MFC/ATL will be used for our new project. I personally think it is a mistake since we can wrap our legacy code in COM and use it in NET.
MFC. There's just something wrong with requiring people to install a 20 MB framework in order to run our product. In the future, sure, we'll use .NET, but for now we'll stick with tried & true MFC. Jon Sagara Help me out here, Spock. I don't speak stupid.
-
How many developers are starting a brand new large scale project using C#/NET? I was just curious. My company has stipulated that C++/MFC/ATL will be used for our new project. I personally think it is a mistake since we can wrap our legacy code in COM and use it in NET.
I am in the process of trying really hard to convince a client that we should use C#/.NET. Part of the system will be web based so ideally we will be using ASP.NET for that, and there are a couple of web services which I want to write in C#, and depending on the route we decide on there may or may not be client side software too, which I would like to write either in C# or MC++. I just feel that it will be easier and far more cost effective to take that route (for the client side) in the long run. The runtime size should hopefully not be a problem given the target audience, so that is the first paving stone laid. Time will tell. :~
David Wulff http://www.davidwulff.co.uk
An orgy in Tiverton... ({) `/\^^/\:p (Z) :$/\^^/\` (})
-
How many developers are starting a brand new large scale project using C#/NET? I was just curious. My company has stipulated that C++/MFC/ATL will be used for our new project. I personally think it is a mistake since we can wrap our legacy code in COM and use it in NET.
Boze wrote: How many developers are starting a brand new large scale project using C#/NET For web applications, my company is shifting towards C#/ASP.NET (although we have faced several nasty bugs in .NET framework), but for everything else C++ is still our preferred tool. Not because of performance, but because of it's features, portability, and most of all - we already have a lot of C++ code which we can reuse. :beer:
-
MFC. There's just something wrong with requiring people to install a 20 MB framework in order to run our product. In the future, sure, we'll use .NET, but for now we'll stick with tried & true MFC. Jon Sagara Help me out here, Spock. I don't speak stupid.
Agreed. And .NET 1.1 is 24MB As a matter of fact, you need more than that (IE6, MDAC2.7, ...). I saw someone somewhere who made an app using VB.NET instead of VB and he ended up installing 190MB of MS run-times, in addition of manually handling the problems. .NET is fine stuff for a lot of futuristic apps such like distributed programming. However, today it's an unproven environment. In the short term, the most added value of .NET is IMHO in the server-side, especially ASP.NET. Using C# and webforms is light years away from what people where used to do with the former ASP stuff. I like the idea of a standardized framework to work with. But that's becoming a true knightmare as releases come (now every quarter, it's a full-time job to figure out the differences between versions). And, on top of that, redistribution is an issue : unlike MFC DLLs you don't control anymore the .NET run-time (the user may update on his own the run-time, thus break the app (worst scenario)). It's unfair to say that COM interop embedded in .NET bridges the former raw COM stuff. In fact, you have a lot of trouble passing parameters in method call depending on the types (and several variant types are not even supported by the marshaller (for instance VARIANT(VARIANT|BYREF), so let me say clearly you are not in a drag&drop situation). Furthermore CCW/RCW marshalling wrappers generated by the environment cannot be debugged as other pieces of code. This, in practice, is a show stopper : it takes much more time than doing the low-level COM stuff instead. My -0.5c
How low can you go ?
(MS retrof_u_ck) -
Boze wrote: How many developers are starting a brand new large scale project using C#/NET For web applications, my company is shifting towards C#/ASP.NET (although we have faced several nasty bugs in .NET framework), but for everything else C++ is still our preferred tool. Not because of performance, but because of it's features, portability, and most of all - we already have a lot of C++ code which we can reuse. :beer:
Nemanja Trifunovic wrote: is shifting towards C#/ASP.NET (although we have faced several nasty bugs in .NET framework Care to elaborate? We are moving towards C#/ASP.NET and so far so good.
Paul Watson
Bluegrass
Cape Town, South Africa -
How many developers are starting a brand new large scale project using C#/NET? I was just curious. My company has stipulated that C++/MFC/ATL will be used for our new project. I personally think it is a mistake since we can wrap our legacy code in COM and use it in NET.
Boze wrote: How many developers are starting a brand new large scale project using C#/NET? We are, but it is for a website so no worries about runtimes and wrapping old COM components and such.
Paul Watson
Bluegrass
Cape Town, South Africa -
How many developers are starting a brand new large scale project using C#/NET? I was just curious. My company has stipulated that C++/MFC/ATL will be used for our new project. I personally think it is a mistake since we can wrap our legacy code in COM and use it in NET.
As much as I'd like to use C# and .NET for a large scale project - unless it involves a lot of web/html and the like then you'll find that it hinders rather than helps get a product out the door. The UI components in .NET are no where near as easy to use (or tried and tested) as MFC. You'll find yourself writing a lot of extra code for things that you take for granted (Wizards for one). I'd wait for the next version if I was you. (Or until Genghis gets off the ground http://www.sellsbrothers.com/tools/genghis/[^]) Michael "I've died for a living in the movies and tv. But the hardest thing I'll ever do is watch my leading ladies, Kiss some other guy while I'm bandaging my knee." -- The Unknown Stuntman
-
Nemanja Trifunovic wrote: is shifting towards C#/ASP.NET (although we have faced several nasty bugs in .NET framework Care to elaborate? We are moving towards C#/ASP.NET and so far so good.
Paul Watson
Bluegrass
Cape Town, South AfricaPaul Watson wrote: Care to elaborate? Sure. this issue is the biggest headache. Paul Watson wrote: We are moving towards C#/ASP.NET and so far so good. Have you tried to host your ASP.NET apps on clusters? :beer:
-
How many developers are starting a brand new large scale project using C#/NET? I was just curious. My company has stipulated that C++/MFC/ATL will be used for our new project. I personally think it is a mistake since we can wrap our legacy code in COM and use it in NET.
-
Agreed. And .NET 1.1 is 24MB As a matter of fact, you need more than that (IE6, MDAC2.7, ...). I saw someone somewhere who made an app using VB.NET instead of VB and he ended up installing 190MB of MS run-times, in addition of manually handling the problems. .NET is fine stuff for a lot of futuristic apps such like distributed programming. However, today it's an unproven environment. In the short term, the most added value of .NET is IMHO in the server-side, especially ASP.NET. Using C# and webforms is light years away from what people where used to do with the former ASP stuff. I like the idea of a standardized framework to work with. But that's becoming a true knightmare as releases come (now every quarter, it's a full-time job to figure out the differences between versions). And, on top of that, redistribution is an issue : unlike MFC DLLs you don't control anymore the .NET run-time (the user may update on his own the run-time, thus break the app (worst scenario)). It's unfair to say that COM interop embedded in .NET bridges the former raw COM stuff. In fact, you have a lot of trouble passing parameters in method call depending on the types (and several variant types are not even supported by the marshaller (for instance VARIANT(VARIANT|BYREF), so let me say clearly you are not in a drag&drop situation). Furthermore CCW/RCW marshalling wrappers generated by the environment cannot be debugged as other pieces of code. This, in practice, is a show stopper : it takes much more time than doing the low-level COM stuff instead. My -0.5c
How low can you go ?
(MS retrof_u_ck)__Stephane Rodriguez__ wrote: And, on top of that, redistribution is an issue : unlike MFC DLLs you don't control anymore the .NET run-time (the user may update on his own the run-time, thus break the app (worst scenario)). Apart from non-breaking service packs, updates to the framework will install in side-by-side mode, which will prevent updates from breaking your app. It also means that you use twice the disk-space, but with the way HDDs are going, do you really care about the odd 20Mb? ;P __Stephane Rodriguez__ wrote: How low can you go ? (MS retrof***) Ahem! Soapbox[^].
-
__Stephane Rodriguez__ wrote: And, on top of that, redistribution is an issue : unlike MFC DLLs you don't control anymore the .NET run-time (the user may update on his own the run-time, thus break the app (worst scenario)). Apart from non-breaking service packs, updates to the framework will install in side-by-side mode, which will prevent updates from breaking your app. It also means that you use twice the disk-space, but with the way HDDs are going, do you really care about the odd 20Mb? ;P __Stephane Rodriguez__ wrote: How low can you go ? (MS retrof***) Ahem! Soapbox[^].
Richard_D wrote: Apart from non-breaking service packs, updates to the framework will install in side-by-side mode, which will prevent updates from breaking your app. Nice MS marketing brochure mate. What I say is from personal experience. Multiple .NET run-times : let's wait the first .NET 1.1 apps come. How many of us will be able to properly configure the apps so they run fine on target machines with either .NET 1.0 or .NET 1.1 run-times ? Just let me guess... By the way, how would you manage it ?
How low can you go ?
(enculage MS) -
Richard_D wrote: Apart from non-breaking service packs, updates to the framework will install in side-by-side mode, which will prevent updates from breaking your app. Nice MS marketing brochure mate. What I say is from personal experience. Multiple .NET run-times : let's wait the first .NET 1.1 apps come. How many of us will be able to properly configure the apps so they run fine on target machines with either .NET 1.0 or .NET 1.1 run-times ? Just let me guess... By the way, how would you manage it ?
How low can you go ?
(enculage MS)__Stephane Rodriguez__ wrote: What I say is from personal experience. Other than beta software, there has only been one version of the .NET framework released, so nobody can speak from personal experience. __Stephane Rodriguez__ wrote: How many of us will be able to properly configure the apps so they run fine on target machines with either .NET 1.0 or .NET 1.1 run-times ? That's not the point. If you build your app with one version, then the machine you deploy it to must have that version installed. AFAIK, unless you statically link to the MFC dlls, they can be updated by the user as well. Since they don't install side-by-side, how would you cope with making your VC++ 6 app work on a machine with only the VC++ 5 runtimes installed? Just my €0.05! ;P
-
__Stephane Rodriguez__ wrote: What I say is from personal experience. Other than beta software, there has only been one version of the .NET framework released, so nobody can speak from personal experience. __Stephane Rodriguez__ wrote: How many of us will be able to properly configure the apps so they run fine on target machines with either .NET 1.0 or .NET 1.1 run-times ? That's not the point. If you build your app with one version, then the machine you deploy it to must have that version installed. AFAIK, unless you statically link to the MFC dlls, they can be updated by the user as well. Since they don't install side-by-side, how would you cope with making your VC++ 6 app work on a machine with only the VC++ 5 runtimes installed? Just my €0.05! ;P
Richard_D wrote: Other than beta software, there has only been one version of the .NET framework released, so nobody can speak from personal experience. Ha ha. Richard_D wrote: That's not the point. If you build your app with one version, then the machine you deploy it to must have that version installed. Which proves you really know what you are talking about... This is true, unless you do something. I am foreseeing that this "something" is highly technical and requires a lot of advanced testing and knowledge of the whole set of .NET run-times and behaviors. Issues with MFC dlls pale in comparison. Richard_D wrote: AFAIK, unless you statically link to the MFC dlls, they can be updated by the user as well. Since they don't install side-by-side, how would you cope with making your VC++ 6 app work on a machine with only the VC++ 5 runtimes installed? Putting the MFC dlls in the app directory doesn't do harm.
How low can you go ?
(enculage MS) -
Richard_D wrote: Other than beta software, there has only been one version of the .NET framework released, so nobody can speak from personal experience. Ha ha. Richard_D wrote: That's not the point. If you build your app with one version, then the machine you deploy it to must have that version installed. Which proves you really know what you are talking about... This is true, unless you do something. I am foreseeing that this "something" is highly technical and requires a lot of advanced testing and knowledge of the whole set of .NET run-times and behaviors. Issues with MFC dlls pale in comparison. Richard_D wrote: AFAIK, unless you statically link to the MFC dlls, they can be updated by the user as well. Since they don't install side-by-side, how would you cope with making your VC++ 6 app work on a machine with only the VC++ 5 runtimes installed? Putting the MFC dlls in the app directory doesn't do harm.
How low can you go ?
(enculage MS)__Stephane Rodriguez__ wrote: Ha ha. :confused: Have Microsoft secretly released another version of the .NET framework without telling us? __Stephane Rodriguez__ wrote: Putting the MFC dlls in the app directory doesn't do harm. Apart from the size, what's the difference between doing this and having multiple versions of the .NET framework installed? Or, for that matter, copying the assemblies you reference to your application directory? Of course, until Microsoft releases a new version of the framework, we're all just guessing what will happen. I can't guarantee your apps won't break, but MS seems to be busting their balls to make sure they won't.
