So Last night I got around to installing VS.NET....
-
So last night I didn't have anything better to do so I installed VS.NET and I'm still left wondering where to start. I have been programming in C++ and MFC for the last 10 years or so and I just can't see the usefullness of VS.NET. I have a couple of questions that I would like to propose to everyone: 1. Can anyone suggest a product/project that MC++ or C# would be a better alternative to than VC6/MFC? 2. What's the usefullness of C#? I've been trying to figure out a project that I would use this for and I still can't come up with one. 3. Where do I even begin? I'm trying to figure out if I want to move our products/components to the VS.NET environment and I'm not sure if we should or not. Everything that we've written is in either MFC applications, MFC OCX controls, win32 DLL's and libs. Any Suggestions? 4. Has anyone else encountered these questions? and how did you deal with them? Thanks, Scott
There is no way that .NET ever beating the speed of C++. You will see problems when you were to do some complicated and low end stuff using .NET. Of course, if that was your point of interest. Sonork 100.41263:Anthony_Yio
-
Let's just say I'm done with the hospitals and therapy stuff, and I don't have full use of the hand. :( The watercololing project will be restarted after the first of the year. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
John Simmons / outlaw programmer wrote: Let's just say I'm done with the hospitals and therapy stuff, and I don't have full use of the hand. :( Do the doctors fell you will regain full use of the hand? (If your not comfortable talking to me about this tell me to pull my head in) John Simmons / outlaw programmer wrote: The watercololing project will be restarted after the first of the year. Look forward to the updates on the website. Michael Martin Australia "I suspect I will be impressed though, I am easy." - Paul Watson 21/09/2003
-
My point was that he could still get real work done without being forced into the .NET crapware. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
-
Matt Philmon wrote: there are no arcane types to deal with Ask Heath, he's putting code snippets all day long and, by judging the length of his posts, I would think it's not that simple. May be it's my own judgement... Matt Philmon wrote: no BSTR's (CURSE YOU TO H*LL BSTR DEVIL) No, you prefer the crude String api right? Have you figured out there is no Right(n) method available? Matt Philmon wrote: no weird COM threading models to deal with (STA/MTA), Sorry mate, last time I checked the [StaThread] is the first thing you add in a .NET app. It's visible in 100% of the apps. Just check it better. Of course, you don't see it because the wizard does it for you by default, but let's discuss about it next time you need multi-threading support. Matt Philmon wrote: ANYONE who can program in C++ can make very short work of the .NET Framework. This can be true, but is not a general rule IMHO. Can be true for projects not needing older code, especially if all the services you need are provided by the BCL. But just in case you need P/Invoke or COM you are pretty much down in the mud. Matt Philmon wrote: C# is nothing more than a replacement for Java A 100% rip-off. (old MS Java VM) Matt Philmon wrote: I've been a C++ COM/MFC developer for several years now and have always really hated VB. How much do you use Reflector. I can't think about programming against the CLR without it. So please don't pretend that the VS.NET environment, especially C# is not exactly VB-like. Unless you have the decompiler, you are pretty much stuck, like a VB guy and his drag and pray environment. My 2 cents. And if this is not obvious from me, there are good things in .NET, I am not against it.
Stephane Rodriguez. wrote: Ask Heath, he's putting code snippets all day long and, by judging the length of his posts, I would think it's not that simple. May be it's my own judgement... Alot of my experience in integrating the ATL COM world with VB6 and ASP forced me to learn a LOT new things and types. It was a huge hassle when needing to be able to write a COM component that could work in a MFC application, a VB6 application, AND be useable in both VBScript and Javascript for use in ASP. The types required to cover all your bases, particularly when dealing with arrays of data... even more so multidimensional arrays was a nightmare of arcane types and strange conversions and tracking down memory leaks in your SAFEARRAYS and BSTRS. I hated every moment of it. Never mind that VBScript can't even deal with multidimensional VARIANT (ugh) arrays unless you flatten it all out and make it nearly unusable. Some might think this isn't a big deal but any time you pull large amounts of data together to display on a web page (large tables) and aren't dealing (necessarily) with a database and ADO you'll quickly find out how much a pain it is. Stephane Rodriguez. wrote: Sorry mate, last time I checked the [StaThread] is the first thing you add in a .NET app. It's visible in 100% of the apps. Just check it better. Of course, you don't see it because the wizard does it for you by default, but let's discuss about it next time you need multi-threading support. STA/MTA is hideous. Yes, I know the wool has been pulled over my eyes a bit on how .NET manages all this but to tell you the truth... I really don't care. Go try to write a COM object sometime that MUST be an STA (VB and ASP require it) but ALSO must be multithreaded AND be able to process Windows messages. Trust me, it's not an easy feat. You have to get down deep into the bowels of marshalling and creating your own message pumps, dealing with things you don't even wanna know about and it's a COMMON problem. If you live in a world of pure MFC and C++ it doesn't make a huge difference.... but nowadays we're all saddled with supporting lots of VB users. Stephane Rodriguez. wrote: This can be true, but is not a general rule IMHO. Can be true for projects not needing older code, especially if all the services you need are provided by the BCL. But just in case you need P/Invoke or COM you are pretty much down in the mud. Yes I agree with you... which is why I said that you
-
Amanjit Gill wrote: Also, you do not want to hear your customers say "Hey you are not using unmanaged code, are you?" Depends on the project. Ok for new, small projects. What about application start-time? What about mission critical software? Impossible to tell TODAY because there is none in production yet. So please, don't make gratuitous claims, or make sure to narrow your experience to what is is limited to (no pun intended). Can you name a MS product made with .NET? I can name you one available on Jan next year, MS Reporting services, and god it's 100 times slower than today's mission critical report engines.
NONE in production yet. You are completely right. Native Apps rule, As you said MS products are still running natively. "Unmanaged" C++ still has the ultimate edge in my eyes - Just think about games. What I wanted to say is this: We are mostly application developers, some are doing system development (performance, scalability) etc, but most of us are application developers - look at the apps we build every day for our living (which probably aren't RDBMS)? So basically we are consuming APIs which provide most of the functionality. If you need a functionality which is provided by a .NET API *ONLY*, you probably have to develop "for .NET". Just think about a high-end gfx card, which contains whatever new Rendering /Radiosity/whatever functionality to you. Now if you are an OpenGL programmer, you probably need GL Extensions rovided by the manufacturer to efficiently use the features of your gfx card. Now if your gfx card functionality is only exposed by DirectX API, you just _have_ to develop with DirectX or you cannot use that functionality. (or the opposite). ______________________________ Java: The living proof Moore's law won't solve all your problems
-
Amanjit Gill wrote: Also, you do not want to hear your customers say "Hey you are not using unmanaged code, are you?" Depends on the project. Ok for new, small projects. What about application start-time? What about mission critical software? Impossible to tell TODAY because there is none in production yet. So please, don't make gratuitous claims, or make sure to narrow your experience to what is is limited to (no pun intended). Can you name a MS product made with .NET? I can name you one available on Jan next year, MS Reporting services, and god it's 100 times slower than today's mission critical report engines.
BTW: - I do MFC/C++ for a living right now - I am not doin .NET at all, and will only use it if I have to. ______________________________ Java: The living proof Moore's law won't solve all your problems
-
My point was that he could still get real work done without being forced into the .NET crapware. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
John Simmons / outlaw programmer wrote: My point was that he could still get real work done without being forced into the .NET crapware. You can get work done writing everything in assembly... or COBOL, PL/I, RPG, or whatever. It's you choice. You'll eventually see the light... or be left behind.
If Java had true garbage collection, most programs would delete themselves upon execution - Robert Sewell
-
Stephane Rodriguez. wrote: Ask Heath, he's putting code snippets all day long and, by judging the length of his posts, I would think it's not that simple. May be it's my own judgement... Alot of my experience in integrating the ATL COM world with VB6 and ASP forced me to learn a LOT new things and types. It was a huge hassle when needing to be able to write a COM component that could work in a MFC application, a VB6 application, AND be useable in both VBScript and Javascript for use in ASP. The types required to cover all your bases, particularly when dealing with arrays of data... even more so multidimensional arrays was a nightmare of arcane types and strange conversions and tracking down memory leaks in your SAFEARRAYS and BSTRS. I hated every moment of it. Never mind that VBScript can't even deal with multidimensional VARIANT (ugh) arrays unless you flatten it all out and make it nearly unusable. Some might think this isn't a big deal but any time you pull large amounts of data together to display on a web page (large tables) and aren't dealing (necessarily) with a database and ADO you'll quickly find out how much a pain it is. Stephane Rodriguez. wrote: Sorry mate, last time I checked the [StaThread] is the first thing you add in a .NET app. It's visible in 100% of the apps. Just check it better. Of course, you don't see it because the wizard does it for you by default, but let's discuss about it next time you need multi-threading support. STA/MTA is hideous. Yes, I know the wool has been pulled over my eyes a bit on how .NET manages all this but to tell you the truth... I really don't care. Go try to write a COM object sometime that MUST be an STA (VB and ASP require it) but ALSO must be multithreaded AND be able to process Windows messages. Trust me, it's not an easy feat. You have to get down deep into the bowels of marshalling and creating your own message pumps, dealing with things you don't even wanna know about and it's a COMMON problem. If you live in a world of pure MFC and C++ it doesn't make a huge difference.... but nowadays we're all saddled with supporting lots of VB users. Stephane Rodriguez. wrote: This can be true, but is not a general rule IMHO. Can be true for projects not needing older code, especially if all the services you need are provided by the BCL. But just in case you need P/Invoke or COM you are pretty much down in the mud. Yes I agree with you... which is why I said that you
Matt Philmon wrote: even more so multidimensional arrays was a nightmare of arcane types and strange conversions and tracking down memory leaks in your SAFEARRAYS and BSTRS. I hated every moment of it I understand. Before committing in this, you have to read the right book first. For that matter, the MSDN doc is just not the right documentation. A lot of troubles could have been avoided but, eh that's thing of the past right now.;) Matt Philmon wrote: If you live in a world of pure MFC and C++ it doesn't make a huge difference.... but nowadays we're all saddled with supporting lots of VB users. Ironically, I think it's a good signal that a lot of veteran consultants that know how to handle that kind of stuff will make the money from now on, just because : 1) the new generation of developers barely know this 2) the old MSDN doc is being silently retired 3) the MSDN doc is not up-to-date and anyway has never been sufficient to allow knowledgeable people to solve that kind of issues by just reading a few articles. So yeah, great news, if you consider you stay in that middle-nowhere. But if you choose to go the higher-level language way, well you know that's the land of free bananas. Matt Philmon wrote: and a COM object is easily referenced in a .NET project. Yes and no. Let's focus on the no. Importing the type library is restricted to a few rules. Today's tlbimp.exe/aximp.exe don't import everything, so unless you write a truly simple COM stuff, you'll lose the stuff in-between (there is a commercial replacement for tlbimp, I'll dig the url for you if you are interested). And on the negative side, you have the performance issues, and the memory leaks. In other words, the way we are today from the .NET point of view regarding RCWs is just the exact same point of view than reusing commercial ActiveX controls with your VB or C++ app. It's full of memory leaks, bugs and can't sustain one hour without failing miserably. Matt Philmon wrote: and a COM object is easily referenced in a .NET project. Another con, did you know the full path to the com component is hardcoded in the csproj file? You won't believe they would have done that. But...they did. You can certainly guess the consequences. Matt Philmon wrote: I'm not pretending anything. I always hated VB. I love VB.NET. It's more robust, I can create full classes that are type safe across the f
-
NONE in production yet. You are completely right. Native Apps rule, As you said MS products are still running natively. "Unmanaged" C++ still has the ultimate edge in my eyes - Just think about games. What I wanted to say is this: We are mostly application developers, some are doing system development (performance, scalability) etc, but most of us are application developers - look at the apps we build every day for our living (which probably aren't RDBMS)? So basically we are consuming APIs which provide most of the functionality. If you need a functionality which is provided by a .NET API *ONLY*, you probably have to develop "for .NET". Just think about a high-end gfx card, which contains whatever new Rendering /Radiosity/whatever functionality to you. Now if you are an OpenGL programmer, you probably need GL Extensions rovided by the manufacturer to efficiently use the features of your gfx card. Now if your gfx card functionality is only exposed by DirectX API, you just _have_ to develop with DirectX or you cannot use that functionality. (or the opposite). ______________________________ Java: The living proof Moore's law won't solve all your problems
Amanjit Gill wrote: So basically we are consuming APIs which provide most of the functionality. If you need a functionality which is provided by a .NET API *ONLY*, you probably have to develop "for .NET". In the long run, people who write core libraries (file format converters for instance) will still be over the edge compared to developers who from now on are more and more "simple users" of APIs. If migrating to .NET allows those that really know how the stuff works together be over the edge and gain advantage over others (job, income, ...) then be it. So far, this has not yet happened. Only hope it will.
-
Stephane Rodriguez. wrote: Ask Heath, he's putting code snippets all day long and, by judging the length of his posts, I would think it's not that simple. May be it's my own judgement... Alot of my experience in integrating the ATL COM world with VB6 and ASP forced me to learn a LOT new things and types. It was a huge hassle when needing to be able to write a COM component that could work in a MFC application, a VB6 application, AND be useable in both VBScript and Javascript for use in ASP. The types required to cover all your bases, particularly when dealing with arrays of data... even more so multidimensional arrays was a nightmare of arcane types and strange conversions and tracking down memory leaks in your SAFEARRAYS and BSTRS. I hated every moment of it. Never mind that VBScript can't even deal with multidimensional VARIANT (ugh) arrays unless you flatten it all out and make it nearly unusable. Some might think this isn't a big deal but any time you pull large amounts of data together to display on a web page (large tables) and aren't dealing (necessarily) with a database and ADO you'll quickly find out how much a pain it is. Stephane Rodriguez. wrote: Sorry mate, last time I checked the [StaThread] is the first thing you add in a .NET app. It's visible in 100% of the apps. Just check it better. Of course, you don't see it because the wizard does it for you by default, but let's discuss about it next time you need multi-threading support. STA/MTA is hideous. Yes, I know the wool has been pulled over my eyes a bit on how .NET manages all this but to tell you the truth... I really don't care. Go try to write a COM object sometime that MUST be an STA (VB and ASP require it) but ALSO must be multithreaded AND be able to process Windows messages. Trust me, it's not an easy feat. You have to get down deep into the bowels of marshalling and creating your own message pumps, dealing with things you don't even wanna know about and it's a COMMON problem. If you live in a world of pure MFC and C++ it doesn't make a huge difference.... but nowadays we're all saddled with supporting lots of VB users. Stephane Rodriguez. wrote: This can be true, but is not a general rule IMHO. Can be true for projects not needing older code, especially if all the services you need are provided by the BCL. But just in case you need P/Invoke or COM you are pretty much down in the mud. Yes I agree with you... which is why I said that you
STA/MTA is hideous. Yes, I know the wool has been pulled over my eyes a bit on how .NET manages all this but to tell you the truth... I really don't care. Go try to write a COM object sometime that MUST be an STA (VB and ASP require it) but ALSO must be multithreaded AND be able to process Windows messages. Trust me, it's not an easy feat. You have to get down deep into the bowels of marshalling and creating your own message pumps, dealing with things you don't even wanna know about and it's a COMMON problem. If you live in a world of pure MFC and C++ it doesn't make a huge difference.... but nowadays we're all saddled with supporting lots of VB users. Excuse my ignorance here, but what particular technique could you use to implement .NET component that simultaneously supports: -- STA, MTA, Windows Messages... What would be that? From what I understand appartment threadind is global in .NET. What exactly do you mean? At least COM supports Free Thread marshalling, so Free Threaded COM component doesn't care. So, what is it in .NET that will make the same component to work purfectly well hosted in STA, MTA and as a Control??? Alot of my experience in integrating the ATL COM world with VB6 and ASP forced me to learn a LOT new things and types. It was a huge hassle when needing to be able to write a COM component that could work in a MFC application, a VB6 application, AND be useable in both VBScript and Javascript for use in ASP. Here I also confused a lot. So, your point is that in .NET you can write components easily accesible from MFC, VB6, VBScript and Javascript? If so, from what I know those one are Interop COM components. Or maybe you are trying to say that you just don't have necessaty now to support MFC, VB6, VBScript and Javascript? If so, that just means that your containers changed: but is this good by itself? So, you are now limited by supporting less poossible clients... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me