|
At my work and in this forum consensus seems to be that the interface is pretty good and stable if you're just programming C#. Try some C++ and especially MFC and everything seems to be annoying and/or flaky. Is this just me?
|
|
|
|
|
I would not say annoying, the usage is pretty much the same to VC6, just that the interface change from class wizard to VB like property list.
No improvement on MFC/ATL is the main issue. As .net framework treat COM/DCOM development differently (the most obvious different is registry), ATL becomes something like "no-way to go". MFC is a framework got constructed over the pass 10 years. It still work and can be extended like DUNDAS/ROGUEWAVE MFC library. However, certain class in MFC is now showing its age, for example those database class and OLE server class. Also, MFC does not seems to catch up with today's network centric requirement.
Fortunately, MS still offer platform SDK to fulfill the gap. Unfortunately, information for C/C++ developer in platform SDK is now either took out, or mention nothing more than .net. Should MS VC++ team go one step further to re-engineer MFC/ATL to better reflect today's C/C++ development? Can we use MFC/ATL to produce application like MS VISIO? As we pay the same amount of $ to buy VS.200x, should MFC/ATL get the same amount of attention? If MS keep sideline native C/C++ development, how long will platform SDK persist? Will VC++ eventually become 100% .net dependent? Judging from performance of DUNDAS/ROGUEWAVE extended MFC class library, I can say there are still a lot of thing MS can improve MFC/ATL. The question is really whether they willing to do so or not?
C# vs C++ is really a wrong question to ask, you should ask: C# vs Java instead. C# is for those who only care to produce MS based-application. C/C++ does not only produce application, with its meta-driven capability, it also provide a solution, a science and freedom. 
|
|
|
|
|
My comments were more aimed at the survey question 'Survey: How satisfied are you with Visual Studio .NET 2003?', specifically to do with the new studio's flakiness/usability.
Your comments on MFC/ATL totally make sense though...MS forces developers to upgrade their studio if they want framework upgrades (MFC 7.1) but make it way harder to work. Its seems like a backhanded way to migrate everyone to C#/VB.net.
In my mind the new stuff is the way to go for the reasons you cited and simply because if you're signed on as a Windows developer MS doesn't seem likely to improve/re-engineer much of older frameworks like MFC. What's upsetting is that the trasition period seems forced upon us too abruptly. Because of this and much to MS's delight, I often think re-writes are better than maintaining old code and trying to integrate it. Oh well...
|
|
|
|
|
New stuff the way to go?? I urged you to look into other system as well, not only Windows. With C/C++, you can work with virtually any system. The IDE designed shows the roadmap of MS. In my point of view, unless there is a commitment from MS to improve MFC/ATL to better reflect Windows technology with the ORIGIN OF C/C++. I foreseen C/C++ will be crippled if not disappear from this platform.
It is just a matter of time people start realize there is no need to blend .net with C/C++. To consume .net, use .net based language is much more natural and efficient. But you are tied to Windows and you don't really "program" anymore, you only learn howto live with .net. Years to come, nothing in your knowledge you can use WITHOUT .net, YOU ARE STUCK FOREVER.
Based on the pass 20 years of C/C++ effords. C/C++ is a real mature language now, some people treat "mature" as "old"...I think this is totally wrong, especially I.T, we need something stable and full prove to run everyday operations. Example nothing match a mainframe in banking sector, not NT4, not W2K, not even W2003.
Same to MFC/ATL, it is mature but that doesn't mean it is old. There is absolutely no need to argue about the 1MB++ MFC/CRT runtime, as .net itself required a 17MB++ runtime! Unfortunately there is no another OWL to drive the momentum of MFC/ATL. That's the problem with monopoly. I sincerely hope that while MS has earned so much, please invest to re-engineer MFC/ATL as a support to C/C++. Until one day we can use MFC/ATL to build an application like VISIO, MFC/ATL is never too old to get improve!
C# is a clone of Java, or a Microsoft extension to Java to better reflect Windows system, just like Java VM is better reflect UNIX core. I have programmed C/C++ for many years, I can tell you everything beside some similarity in syntax, there is absolutely nothing the same between the two.
|
|
|
|
|
You can use wxWindows (wswindows.org) instead MFC. It's opensource multiplatform (Win,Lin, MAC) MFC like C++ library.
|
|
|
|
|
I've been using VS.NET now since it was in early beta. The only different I really noticed between 2002 and 2003 is an improvement in stability. The major issues, for me at least, are still there.
1. No support for CVS or any other source control system except for Microsoft Source Safe.
2. The representation of the development environment that is used for macros is really strange. I have had a lot of problems getting it to do what I want it too. Usually I have to resort to recording a macro that makes use of the things that I want to do and then editing it. Also I would like to be able to create my macros in C# or any .NET language. (Maybe you can already do this?)
3. I would like the ability to have some keys trigger context dependent expansions. I have hooked up the backet key "{" so that it expands into one open and one closed with a line separating them with the cursor at the place were I would like to type next. I have not been able to attach a similar macro to the "(" key. That's sort of inconsistent I find.
4. I would like the IDE to sort my "using *" statements or maybe even tell me with are unnecessary. After a while with an evolving code base I tend to get tons of using statements at the beginning of the file because I never know which are no longer necessary.
5. Does the class view update automatically to show me where I am in the class hierarchy as I move through C# files? I thought it did once but it doesn't seem to do this any more. That sort of sucks.
6. I have a lot of projects in my solutions (not to mention a lot of code as well.) I would like to organize my projects in a solution via some folders. I would like one folder which is called "Libraries" in which I place my shared libraries. Thus I can easily keep the main application projects separate from the library projects.
7. I would like to specify C# files which are executing during compilation -- these files can basically act as super templates since they have access to the codeDOMs which the compiler is using. I would use these compilation time execution files to generate more code that I find useful. I would also like to be able to attach arbrary input files to these files in the project view. I believe some types of table-based code generation would be quite useful.
I think that is about it for now. I guess I am mostly concerned about the features in .NET. I really really need templates/generics. I also really really need 64 bit computing.
Cheers.
|
|
|
|
|
Ben @ Exocortex.ORg wrote:
No support for CVS or any other source control system except for Microsoft Source Safe.
It supports Rational Clear Case and there is a addin of sort for the gotdotnet workspace, the clear case is the one I use at work and works fine (except for a minor bug which prevented integeration with vs.net 2003, but that was from rational's end and a small reg. tweak sorts out the problem)
Cheers,
Kannan
|
|
|
|
|
I've had some issues with .NET 2002 and ClearCase - specifically, .NET insists on trying to create elements every so often (I think it's an attempt to figure out what permissions it has to work with).
Directory elements get checked out and a dodgy file (beginning with "~sak") gets added to the directory file list. Only it doesn't exist. It's damn annoying! Do you get that problem (you may not even notice it unless you have a look at the history of some of your directories), and is there any work around?
Another one - if you try to add an existing item to a project .NET insists on trying to add it to the source control system - without asking...and often I don't want it to do that.
There's a number of other problems we've had (checking files in/out from outside of Visual Studio causes it to lose track of the status of files - even if you try to Refresh the Status, which takes aaaages....I could go on!) so I wouldn't say the source control support is great with ClearCase (unless it's been fixed with 2003).
There are _lots_ of other things about VS.NET I do like - this isn't one of them.
|
|
|
|
|
|
...because it's far from perfect and someone should 
1. Right click on control on a dialog. Choose add variable. Wait for slllooow dialog to appear, enter variable name, click finish. Now watch as it switches to the class in question in the editor, hiding the dialog. That's pretty annoying when adding, say, five at the same time. Time consuming. Pointless.
2. VS' insane desire to #include header files (and not only that but it prefixes the filename with './' causing it to look one directory up) every time you add a function to a class - e.g. add a WM_PAINT handler to a class. You can end up with a whole table of the things at the top of the class. Oh dear.
3. Editor Tabs. Oh deary deary me. Sorry but i've lived with VS 6 and wndtabs for too long to put up with this lame-ass implementation from MS. First, why put the tabs on the top of the frame? Prefer them at the bottom. But that's not even NEARLY as annoying as when you have more tabs than screenwidth and then (ARGGGGGHH) it decides to put some helpful scroll buttons to one side, instead of doing the nice thang and adding a new row of tabs. Gosh, that really sucks!
4. Speed. Or lack of it. Some of us are stuck with 1ghz machines. Some of us have just 512mb. It feels like someone poured treacle into the top of the computer. Doubtless this is the fault of the 'wonderous' .NET framework. Yuck.
5. Toolbox. Happily appears when you edit a dialog, sadly doesn't do the decent thing and go on vacation when you're not. Ooops.
6. Task List. The window of evil. It cannot be killed and will absolutely 100% guaranteed jump in front of the useful build/debug window at JUST the right moment to annoy you. Yes, i'd like to see my build, or my debug output or even my autos list INSTEAD of a task list which i have no need for. At all. Ever!
7. Collapsable(sp?) Code. Fine and dandy if you want it - what if you don't? Oh, i hear you say you can turn that off? True, but only for a seemingly random period of time after which it'll turn itself merrily back on. Hurrah!
8. Intellisense. Never has a thing been so misnamed. Visual Assist improves this immesurably, but not when writing managed C++ and using the shiny new framework. Bah!
9. So you want to start a debugging session for your OCX control or DLL then? Well you need to select an executable for the debug session. Guess what - they still haven't come up with the simple idea of letting you select from a history list. Some of us test with MORE THAN ONE EXECUTABLE. Radical thinking? Perhaps not. How long has this been like this? I can't remember but several versions at least.
10. Remember when you could cancel a file search just but pressing the same hotkey that you set up to show the find dialog? Yup, that's gone. Far too useful.
...but at least it's more stable than the 2002 version!
Sorry, but it's narking me off big time atm and this isn't even nearly a complete list of gripes with it.
Rant off, beer ingestion begins..
|
|
|
|
|
Oh, almost forgot...
11. Wizards are all over the shot - it's kinda of sloppy and most of them suffer from weird script crashes or other oddities. I have to say i feel most of these are worse than their VC 6 equivilents.
Tim Stubbs
|
|
|
|
|
what I've found a bit annoying (apart all the other well described points) was the product life cycle :
for example, company like compuware (numega) still haven't ported their plug in products (Boundchecker, Truetime, etc.) from 7.0 (2002) to 7.1 (2003)...
So, you can't use their product for the new 2003 version. And they are not the only one.
Seems like even the big company are tyred to updated their products with
this life cycle...
|
|
|
|
|
Still on V2002 here 
|
|
|
|
|
You aren't the only one 
"We will thrive in the new environment, leaping across space and time, everywhere and nowhere, like air or radiation, redundant, self-replicating, and always evolving." -unspecified individual
|
|
|
|
|
I voted for Very Satisfied ...
Reason... check out non-microsoft IDEs out in the market.
I used one of the well-known IDEs to develop java client application. I would say that was the worst experience I ever had in my life.
Also, I used an IDE that claims to be the best IDE available to develop and deploy EJBs. It crashed 10 times a day and it needed 1GB RAM ... and a lot more
|
|
|
|
|
Have you tried IntelliJ's IDEA[^]? For server-side Java development it's the best I've seen -- features galore!
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
Alvaro Mendez wrote:
Have you tried IntelliJ's IDEA[^]?
I agree! IMHO IntelliJ is by far the best out there.
-------------------------------
Joan
MomComputerGeek.com
|
|
|
|
|
Looks very good but I don't develop in java anymore and if it does not have academic licencing it is way more expensive than VC.NET for me (which costs less than $100)...
John
|
|
|
|
|
We primarily do web development, and we took a big productivity hit when moving from Java/IDEA to C#/VS.NET, largely due to the IDE. The languages are comparable, but it constantly amazes me to hear that people are happy with the VS.NET IDE. I sure wish someone would come up with a C# version of IDEA. 
The VS.NET 2003 version integration with source control is flaky. When you get an entire project, it takes forever and the solution explorer flickers and jumps and hops and generally freaks out. Then you need to restart the IDE before attempting to rebuild, otherwise the build will fail. We've simply resorted to quitting the IDE, getting everything from SourceSafe, and then reloading the IDE. Single-file operations work fine. Removing files from a project works okay, until another developer sees that he has files that aren't checked in (the ones that were just deleted). More than once, this has resulted in people unwittingly undoing each other's changes.
I despise the whole concept of Solution-file based builds. Major productivity loss. In contrast, I love the directory-based model of Java plus ANT. It's simple to understand, entirely customizable, and I don't have to check out a project file to add a new class. These VS.NET project files become a huge source of contention among developers who want to add files but test their changes before checking anything in... but another developer needs to do that too... bam... someone has to wait. We've had to enable multiple checkouts to get back to normal, but we have to be careful that the project merges work correctly.
I find it impractical to extend the Solution/Project build process to incorporate anything that VS.NET doesn't already support. Good luck if you want to insert some extra actions in the middle of a build (e.g. generate some files). For example, we could not find a way to automate the building of independent .resources files.
If you want to rename a class file that's in a VS.NET Project and in SourceSafe, sit down and plan it out and test it... because it won't just work. If you want to reorganize your directory structure, allocate time... because it won't be simple.
The list goes on and on and on. Anytime an executive or manager or marketing person tells me that VS.NET is more productive, I have to laugh. 
I definitely don't like the VS.NET IDE, but I do like a lot of things about .NET development... until you run into something that Microsoft didn't consider, and you can't extend their solution, so you're basically screwed.
|
|
|
|
|
...even though I've had the following problems:
ASP.NET HTML View buggers things up far too easily.
Editing stored procedures is great, until you have several similarly named ones open and you have to rely on the tooltip to find the right one to edit (try it).
Can't drag-and-drop ASP.NET controls in HTML view.
Screen Real Estate prices going up due to number of things on screen (takes a while to get that sorted out ).
Not being able to drag an edit window from the tabstrip, and edit it on your second monitor while looking at something else on the first.
Solution Explorer, and it's relative clunkiness to the equivalent in VC++6.
MSDN 2003's insistence on loading new pages over the web when you just want to look at some API's definition, and then fails to load the page.
Script Debugging.
Trying to debug someone elses Web Project, and having to manually edit the vbproj or csproj to get it to point at the right thing.
Generates complete crap for COM interop with ADOX (at least, it didn't work properly for me).
Casting an sqldbtype.bit (with value 1) to a system.integer in VB.NET results in the value -1. (Strictly, not an IDE issue, but still a nuisance)
Intellisense for API parameter lists gets in the way when you try to move up/down a line using the cursors after editing an existing line.
While it's never crashed on me, it feels less "solid" than VS6, which crashed all the time.
Sometimes an ASP.NET project won't allow you to start debugging because a component didn't build, but with no error message why, and it works again if you rebuild the solution.
And probably some others I missed.
--
Ian Darling
If I was any more loopy, I'd be infinite.
|
|
|
|
|
Ian Darling wrote:
ASP.NET HTML View buggers things up far too easily.
Amen brother. I actuallyed emailed the head of MS dev here in SA and asked that in VS2003 could the Design View button be physically disabled.
Ian Darling wrote:
Trying to debug someone elses Web Project, and having to manually edit the vbproj or csproj to get it to point at the right thing
I think the whole .csproj, .sou, .sln, .bliksem thing is madness. I can understand big desktop apps having complex project config requirements but really not ASP.NET apps. Can be very frustrating copying projects around and trying to open them in VS.NET.
Ian Darling wrote:
And probably some others I missed.
One of my favourites is the "Newline in constant" bug. Farking hell that can be annoying.
Paul Watson
Bluegrass
Cape Town, South Africa
Crikey! ain't life grand?
|
|
|
|
|
Ian Darling wrote:
And probably some others I missed.
Paul Watson wrote:
One of my favourites is the "Newline in constant" bug. Farking hell that can be annoying
Now I remember another one. If you set VS to put (double) quotes in for ASP.NET/HTML tag attibutes, and then do some databinding with an expression that includes double quotes, you can't switch *back* to Design View, unless you change the quotes it put in from double to single quotes, because it can't parse the thing properly, it seems 
--
Ian Darling
If I was any more loopy, I'd be infinite.
|
|
|
|
|
Hi!
You can look into changes made by Microsoft and will see that all they touch only NET technologies... changes takes only NET part of studio.
Of course they make 2003 more stable then 2002, but it still after day of work it use all my computer memory (1GB)...
2003 is good enough and I setisfied by it in most cases, but debugger still good only for c++ developers... no code chages in runtime without recompile (which c++ developers has all time).
Studio has many too small problems and they make me sometimes dizzy.
for example: floating/docking windows. I make Output window as auto hidden and resize it to big size (2/3 of stusio window size). After compilation (output window automatically shown by studio to me) if studio does not have any open file for edit auto hide of output windows does not work. It's not a big problem, but this can make someone dizzy too.
Good Luck
Alex Kucherenko
|
|
|
|
|
o Being able to open 2 .rc files and drag dialogs bewteen them.
o Being able to open and .exe and copy resources.
Other than that it's cool for people doing VC6.0 work despite what the critics say, it's definetly work upgrading to.
|
|
|
|
|
Normski wrote:
Being able to open 2 .rc files and drag dialogs bewteen them.
You can work around the problem by opening an RC file (Source) from the
File -> Open - > File and then open the second RC file (target) from the File -> Open -> File menu. Now go to source file right click on the dialog resource click copy and go to the target rc and then right click and paste.
Very intutive
I haven't tried with the other one, it was always cool to open an .exe and see all the hidden stuff, but now I use Resource Hacker tool, thats really cool thing.
- Kannan
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
