A question to those of you who already looked at VS2010. How big are the changes that add-in developers will have to make in order to get their add-ins working under VS2010?
As luck would have it I've just written about this exact subject and shown what it took to upgrade my add-in. (links below)
Basically your answer is that there is a low-impact migration, because a back-wards compatible "shim" is in place for most functionality. Understandably though, to get the new stuff in 2010 like MAF, MEF, and WPF there will be some work on the developers part.
http://jb-brown.blogspot.com/2008/11/migrating-visual-studio-add-in-to-2010.html
http://jb-brown.blogspot.com/2008/11/migrating-visual-studio-add-in-to-2010_29.html
(more to come)
Lastly - Be sure to read this outstanding post from Carlos Quintero, MVP about Add-Ins, Frameworks and CLR compatibility. Carlos's blog is the best I've found for add-in stuff.
We've already migrated a development version of our Visual Lint product to VS2010, and for the most part the migration was straightforward - or would have been if there weren't so many bugs in the Visual Studio 2010 Beta 1 automation model. The experience has been akin to the work we had to do to support VS2005 (by contrast VS2008 was a breeze), so it's obvious that VS2010 represents a major change in the evolution of Visual Studio.
As we're using the same binary for all versions of Visual Studio we support (which means the code is contstained to be native C++ throughout), breaking changes in the interfaces tend to be quite visible to us. This time, the areas which have caused us issues are:
The new .vcxproj project file format (we parse project files to read project properties as that's more reliable across multiple Visual Studio versions than using VCProjectEngine - the Visual C++ automation model). Hence we had to write a new parser for .vcxproj files, and as they are potentially very complex that was a major task in itself.
Various bugs in the command bar/command interfaces (presumably related to the new WPF editor/command bar integration). Carlos Quintero has blogged extensively about this subject, so if you have concerns in this area you would be well advised to read his blog.
An undocumented change to the add-in startup sequence in Beta 1 which meant that the DTE Window interfaces were not functional until the OnStartupComplete event had occured. MS have informed us that they are reversing this particular change in Beta 2 due to potential compatibility issues, but we've desensitised our code to this one now, anyway.
Toolwindows in Beta 1 can't be created by internal CLSID (though ProgID works OK). This is the last one we're waiting on before we can wrap up the last major bit of the port.
I suspect that our experience will be pretty representative for most add-ins - it is only if you are using the areas affected directly by major changes in Visual Studio itself (e.g. editor or intellisense integration) that the effects are likely to be particularly severe.
Finally, we're not planning to migrate the build itself to VS2010; it is currently built in VS2008, and we quite simply can't see any reason to migrate to an IDE which is showing every sign of still being a "work in progress" even when it RTMs later this year (that's just my personal opinion though - YMMV).
Related
I'm working for a company which maintain several Desktop application projects written in C++. All of these apps have complex GUI interfaces. What I mean by "complex" is, among others, interfaces with many components, deep component hierarchy, usage of frames, third party and/or custom component packages which support features like transparency and animation.
Until now we always used the Embarcadero RAD Studio suite to write and maintain our apps. However the many recurring bugs of each new version has tired my superiors, and now they are considering the possibility to migrate to Visual Studio.
I think that migrate the application core functions written in c++ will not be a real issue.
However for the GUI it's an other story. I had a previous experience with complex interfaces under the Visual Studio 2003 compiler, and I remember that this was a painful work to create and maintain them. There was no real designer, components were limited, and a huge part of the job was to be done manually. From that I took a look on the designing tools provided with Visual Studio 2017, and my first impression is that not much has changed since. The designer for c++ projects is still so rudimentary, especially in comparison to the RAD Studio VCL, with its well-supplied component library. The C# API is closer than what I need, but I cannot envisage to rewrite all my code in C# as a serious option.
I tried to search tutorials about the good practices to apply in a such situation, but until now I found no helpful info.
My questions are:
Can I recover my current GUI interface, at least a part of it, while I migrate to Visual Studio, or do I have to plan to rewrite everything from scratch?
Does Visual Studio provide a mechanism similar to VCL for composing GUI interfaces, installing third parties packages and writing custom components? And if yes, where can I find relevant info about that?
Is a such port possible without a high dose of headache and tears? Where can I found relevant info about a such process?
I am also currently working on a product which is developed using Embarcadero RAD Studio and some 3rd party UI controls. Development was done many years back, so its UI is quite older style. I tried to migrate it in Visual Studio, by developing application logic in C++ and UI in C#(WPF). But it is as good as writing new application, cost is more. So we discontinued that exercise. However what I learned during this is –
Migrating VCL application from RAD Studio to Visual Studio is like writing new application. There is no one-to-one mapping(data types, stuctures, UI controls etc), you have start from scratch. Also there are no tools available which can help this migration.
Some data types, data structures, UI controls are easily available in RAD Studio, which are not available in Visual C++ (MFC), and vice versa. So you have to review every code line while migrating the application logic.
There are no 3rd party UI controls available for Visual C++(MFC) which can make your life easy. For RAD Studio you have LMD tools, businessSkinForms etc.
After working on RAD Studio over 5+ years, Developing UI is quite easy in RAD Studio (UI in C++). However in Visual Studio you can develop your UI in C#(WPF) which will be rich and can communicate with application logic written in C++.
As you said, you have several desktop applications developed with RAD Studio, while migrating to Visual Studio start with smaller and standalone application. So you will get some confidence during migration of this application and then you can put such migrated small application in production one by one without impact.
~Nilesh
Several years ago, I did some pretty serious Office add-in development for Office 2003 (Word, Excel and PowerPoint). I created some shared COM add-ins in C# using Visual Studio 2003. At the time, I looked at VSTO, but decided for reasons that I can't fully remember that it was not suitable for my needs.
My add-ins are due for an upgrade now, and no longer need to support Office 2003 - though they do still need to support Office 2007, not just 2010.
I know that things have moved on significantly, and that Visual Studio 2010 has better support for Office development. I'd like to determine whether I should re-implement my add-ins using VSTO, or continue with the shared COM add-in route.
If anyone knows of a nice summary of the pros and cons of each approach (beyond the marketing hype), I'd love to hear it.
Things that I found very frustrating first time around (not using VSTO, but may apply anyway):
the need to manage COM references explicitly (and call
ReleaseComObject everywhere)
the need for a COM shim to get the security model to work
visual studio installation projects just plain didn't work; I ended
up building my own MSI-based installer
lack of documentation, particularly on all of the above; I spent
weeks of trial-and-error and searching random blogs; the MS-supplied
example code completely ignored all of these real-world issues
It's also worth mentioning that minimising the amount of stuff that needs to be installed prior to my add-ins is important. I think that one of the things that put me off VSTO was the need to deploy additional stuff (though since I never went down that route I don't know if that concern was justified). And I'd really like to be able to deploy on a standard Windows 7 (or Vista) build without the need to first install (say) .NET 4.
Partial answer but too long to fit in a comment:
Parts I can comment on:
Setup projects for VSTO addins now do actually work and there is a very good walkthrough available on how to create them properly.
Documentation in general of the office object model is poor imho and that should be equally annoying for com and c# development. Because a lot of the objects are now returned as dynamics if you use .net framework v4 you loose intellisense which does not help. The workaround for that is to be explicit in casting to known types where possible.
In order to run it obviously needs the relevant framework installed (v4 is FAR better for this than earlier version because of dynamics, optional arguments that were added under pressure from the office group and the NoPIA setting) Besides that it also needs the VSTO runtime installed.
All of these dependencies could be incorporated into the installer but they are required
You haven't specified what you used to create those com addins (My guess is c++ or vb6) and I can't tell how large they are and how much overhaul they need so it's not really possible to give advice if now is the time to make the change. One of the areas where moving to c# will certainly be far cleaner and nicer is anything related to ribbons. But again I can't estimate how relevant that is for you.
I come from a strong Java background and in recent years have been also developing in C#.
What I can never understand is how far behind (Personal Opinion) the Visual Studio IDE's are in compared with Intelli-J IDEA and Eclipse (Java).
There have been improvements by Microsoft from VS 2005 to VS 2008, but I feel they are not quite there in terms of taking the development experience to the next level.
What I want to know is, is VS 2010 any different?
Why is it that the tools and syntax editors are so much more "evolved" in the Java IDE's.
Just to name a few:
Code Completion (Much more advance in Java IDE's)
Ant Integration (Eclipse and IDEA) vs Visual Studio Build Events
Lack of Code Repository integration in VS (Subversion and CVS) out of the box.
Lack of Advance Re-factoring Tools in Visual Studio.
Thanks.
A few points…
People tend to like what they know.
It is quicker to get up-to-speed in C# as the IDE and most of the tools / docs come from a single source.
In the Java world you have a lot more chooses, this is great for expert that spend times learning about them all, but does also lead to its own problems.
Adding ReSharper or Refactor to Visual Studio may give you what you want.
The Visual Studio debugging is great.
Visual Studio tries to make life easy for you by trying to find missing dlls etc and then storing where they are in the registry. This may be great for a 1 man project, but can often lead to build problems across developer’s machines if you are not careful. In the Java world you have to edit more config file by hand, but at least you can put these files under source code control.
There is not a small command line tool that works well on a build server that will build all types of Visual Studio projects. However in day to day usage you don’t need to learn how to use command tools, as Visual Studio hides them form you.
I think these days most programmers
are just happier with the IDE they
know best.
Note I wrote this over 6 years ago, since then C#/.Net has got a lot more complex, with lots of open source projects. Microsoft has also open sourced a lot of the .net framework. For web and server side development I expect there is now little to choose between the Java world and the .Net world. For “smart clients” .net still have a lot to offer including the new support from cross device phone development.
For multi-threaded IO, I think c# is years ahead of Java, but that could change as C# and Java keeps learning from each other...
Visual Studio has definitely been coming on over the last few years - although many of the improvements have basically been things that Eclipse has had for ages (I haven't used IDEA myself).
You may well want to look at ReSharper, which brings more goodness to Visual Studio, along with the VS2010 Productivity PowerTools.
Also, have a look at Scott Guthrie's blog series about improvements in VS2010. Lots of goodies in there.
All tools have their strengths and weaknesses - these days I'm about as happy in Visual Studio as in Eclipse... although I'm much happier writing C# than Java :) One area where Visual Studio really shines is debugging though... I find things like the VS Watch window to be much better than Eclipse's equivalent.
Visual studio 2017 is still far far behind Intellij IDEA. I'm using both and i can say that even VS2017 with ReSharper is not comparable with IDEA.
Biggest problem for me is that VS still doesn't offer usable hot reload debugging experience. I'm crying every time i have to rebuild my .NET MVC project (it is +- fast, but IIS Express load time ~ 15s EVERY time you make even the smallest change in your code).
If you want to argue with "Edit and continue" so so hotreload function - it is absolutely useless, you can't do almost any change in code without rebuilding (and everytime you have to manually break code and close opened tab with useless information).
So i'm really looking forward for full version of IntelliJ Rider bringing all super user friendly possibilities of IntelliJ IDEA to the .NET world!
I don't agree with you. I think VS is much more easy to use.
For example, when i need to create a web application. I open VS and create a new project (Web Application). After the project created, i press f5 and tadda!...
But if want to create my web application with Java, i need to install a server or some frameworks. Still i don't know how can i create a web application?
Or, Windows Application.
At VS, you don't need do any thing to create a windows based application like web application. but if i want to create windows based application with Java, i had to do something.
I think VS IDE is more user friendly than Java IDE's.
Is it safe to use the beta versions of Visual Studio?
By safe I mean, while developing any project in this studio, is it probable that it may cause some losses to my project? Or any other kind of risk?
Should I just use the studio 2008 and
wait for the stable version of Studio
2010?
Purpose of the question: I am doing my graduation project in .NET framework (includes - C#, WPF etc.).So I don't want to put my project at any risk because of some issue regarding (beta) visual studio.Hence the question.
As long as you are using a version control system, there should be no problem. Simply check out your project (or better yet, create a vs2010 branch) to an experimental folder and work from there.
There are no hidden risks when you use version control appropriately.
Visual Studio 2010 will convert your project files to its new format, meaning you'll have trouble if you want to go back to VS2008 later. I'd suggest holding off for now unless you can find a way to keep both old and new versions of the project files up to date.
There's always a risk in using beta software (but then again, there's always a risk in using any software). The whole reason it's called beta is because the company is not confident that it's got all the bugs worked out. Otherwise, it would have been released so they could start raking in the moola.
There are quite a few ways to mitigate the possibility of any beta software (not limited to VS2010 or even any programming-related product) from causing you trouble. Choose any from this list, which is by no means exhaustive:
Don't use it on the same data (be it accounting information or source code) until you've run it in parallel and gotten the same results as with the older version.
Plan a backout strategy if the software is so bad that it's easier to go back than to try and go forward.
Backup your data even more frequently during the periods where you're using the beta software, up until the point that you're comfortable with it and can revert to a more normal backup strategy.
Don't use beta software at all - wait for the real release (or SP1 if you want to be even safer). There may not be a driving force behind updating to the latest version.
As a company, limit your exposure to the beta software to a small set of your employees. So, for example, if you have six different teams, choose the least important as a sacrificial lamb, so to speak.
My own personal preference is to wait until everyone else has sorted out the problems first. I didn't upgrade to the latest Ubuntu while it was in beta (I still got burnt a little bit with the video and X but that particular problem already had a solution on the net). I don't download the latest and greatest Eclipse until it's been in use for a few months. I'm still using VS2008 under Windows XP since there's nothing I think I need in the latest release (of VS or Windows).
We obviously have the latest and greatest OS' in our test environments but they're crash-and-burn environments that won't cause any real pain if they blow up (other than a rebuild but even that's pretty painless nowadays).
For your particular circumstance, I would probably stick with a tried and true version. You don't seem to have a pressing need for any of the new features in your question and the sort of failure you're talking about is not just losing some information at work which, while annoying, is probably backed up to the point where your career would survive.
A similar loss of your educational work would affect you for a long time if you fail your subject because of it. I would probably just concentrate on getting it finished rather than worrying about what VS2010 beta might do to my work. Don't misunderstand me, you should still be protecting your work even with VS2008 but I'd personally feel safer with that option.
Then, if you have some spare time at the end of your project (hah! as if that would happen!), you could try to convert what you've done so far to VS2010. If it all goes pear-shaped, you still have all the VS2008 stuff available.
There is certainly risk in using unproven software in that it could behave unexpectedly. Some of the answers here focus on protecting your source code and that is a valid concern, but you should also consider other risks.
Could Visual Studio 2010 make your system unstable? Having your source code in a local instance of source control won't do you much good if Visual Studio corrupts your hard drive. Even if you backed up regularly, you'd still be out a good day or two (MINIMUM) rebuilding your desktop.
Also, what do you intend to do with the finished product? Will a professor attempt to open the project on their own desktop? Are you expected to deploy it to another environment? We see these "Works on my computer" problems using proven software, a beta certainly increases the probability of running into this type of problem.
So yes, there is certainly increased risk in using a beta. You can take steps to mitigate the risks but with important work those are steps you should be taking anyway. Is the benefit of using Visual Studio 2010 worth the increased probability of delays / data loss / grade impact?
I know I'm experimenting with VS2010 and I haven't seen severe problems but betas are not proven/guaranteed - the overall risk is probably slight but it is a risk nonetheless.
I guess I would approach the question differently...Is there any real value in using VS 2010 over 2008? I have been using both for a while and I would say, No.
I have had some mysterious crashes with VS 2010 and the application has disappeared on me, causing me to lose any unsaved data.
If you are integrating IronPython / Ruby or working with Office or VB style COM, there is more support for this in .NET 4.0. Beyond that, most of the changes add some shine to the IDE, but not much real value.
my 2 cents.
The biggest risks you will face are crashes, random tool window misplacements, and occasionally Visual Studio will refuse to start and you will have to reset all your settings to have it working again. 1 (I am anyway reasonably happy with Visual Studio 2010 and don't regret having installed it; in my case the compelling reasons were unit testing and visual designer for Silverlight)
But as ocdecio says, there should not be danger for your code, especially if you use a source control system.
As an additional advise, target your projects to .NET Framework 3.5. Using a beta development tool may be ok, using a beta .NET Framework in a production environment is usually not.
1 This crash is supposed to be caused by using raster fonts for the code editor, but it has happened to me without using this type of fonts.
Given that you've said the project will be "tested on another system", the answer is simple: use VS2008. VS2010 solutions cannot be opened by earlier versions, and I wouldn't bet my graduation project on whether or not someone else has VS2010 installed.
Other reasons to stick with VS2008:
VS2010 probably doesn't gain you much.
There are bugs, and I'd rather be working on getting my graduation project done rather than working around problems with my development tool.
If you need help along the way, those that can potentially help probably aren't using the same version. That may make a difference, it may not.
Another thing to consider.. usually the EULA prohibits you from deploying and/or shipping a product using a Beta version of the toolset. I'm not sure this applies in your situation but it's a point to consider.
Another potential issue I've heard of is that sometimes Visual Studio betas refuse to uninstall when it comes time to put in the RTM version. So as long as you don't mind reinstalling Windows when you're ready to install RTM and you've taken the other answers into consideration, then go ahead.
Since your project is for a graduation project and not for full production release, I would say use the latest/stable version of Visual Studio 2010.
You will gain more than you will lose as you will be using the latest technology which will be more useful going forward.
There is an issue for touch screen machines which may render WPF applications unusable.
A workaround exists. See details:
‘MS.Win32.Penimc.UnsafeNativeMethods’ Threw An Exception
fix: C:\Windows\Microsoft.NET\Framework\v3.0\WPF>regsvr32 PenIMC.dll
The biggest problem I have with VS2010 Beta 2 is designer. The Windows Form Designer generates buggy code (Microsoft Connect bug id 507267 and 499925). So I have to edit the form in older version of Visual Studio
I have a few other problems not related to code lose, like random crashing and wizard disappearing.
I've just spent two weeks in VS 2010 beta 2 doing some serious prototyping work. It all went pretty smoothly, and I really like VS 2010. At the end, I moved all the code back to VS 2005 and integrated it with my current project. My experience:
Moving the code back to 2005 was pretty easy. I did try not to use any C# features from 2008 or 2010. The only thing I missed was C#'s implicit properties, but those are easily fixed.
Yes, the project and solution files are not backward compatible. To migrate back, I just created new projects in 2005, and pasted the source files in through Visual Studio. Worked like a charm.
I did find one thing that would consistently crash 2010. If you use the splitter to view two different sections of a file at once, and cut-and-paste from one pane to the other, VS 2010 will roll over and die pretty quickly (not necessarily at the time of the cut-and-paste, but very soon afterwards).
There are some nice productivity features in 2010. You can drag a tab out and make it a window. In Windows 7, you can drag it to the top of the screen to maximize, or to the side to use have the screen. Dragging one file to one side of the screen, and another file to the other side, means you get the whole screen to edit two files, side by side. Very nice. (Even better on two monitors, but I was on a laptop.) The "Quick Find" dialog can now be docked -- that's a huge improvement.
As others have mentioned, use source control, but VS 2010 really is not unstable enough to be any more of an issue than VS 2008. Note that Team Foundation Server 2010 is also available in beta, and will be part of all MSDN subscriptions. It installs under Win7 and Vista. I'm using it for source control on my laptop! Team Explorer is integrated into VS 2010.
I am thinking of creating a product based on the Visual Studio Shell (primarily isolated mode). Since Visual Studio 2010 will most likely be RTM before my product, does it make sense to start with VS2010 as a base rather than VS2008?
Has anyone looked at what they changed in connection to the shell framework and if it is improved enough to warrant using it over the better documented and not-beta 2008?
The editor extensability model is changed radically since it is based off MEF and WPF in 2010. If you extend the editor on 2008, it is likely you will have to make quite a few changes to get stuff working in 2010.
However, a large amount of the extensability still depends on the old VSIP/COM which remain unchanged.
If you plan on shipping with the 2010 time frame I think skipping 2008 is not a bad idea.
Speaking as one who is working on a product based on VS2008 shell I would strongly suggest to use VS2010 instead as base. They have cleaned up their interface and probably fixed a lot of the bugs that are in the VS2008 shell. I think they would also be more sensitive to bugs than when they happen in the "old" VSShell.
This is really not a technical question, in my mind - you need to think about your customers before yourself - is there a large enough crowd of people who use vs08?
(I encountered a similar question and concluded that for my scenario - I need to support VS08)