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
Related
Visual studio 2012, being run under desktop mode under windows 8. Doesn't share the look of other windows 8 desktop applications.
How was this GUI achieved?
Did Microsoft scrap MFC/Winapi altogether (since its so different) and use Direct2d to create the custom gui? Or, have they just made calls to Winapi to customize it they way it looks?
Is there any shortcut for us developers to implement the vs2012 theme in our applications? Using the MFC Application template wizard we can chose from many themes but no vs2012 alike is available.
Indeed, Visual Studio 2010/2012 leverages WPF.
LEVERAGING WPF
WPF utilizes DirectX. WPF attempts to provide a consistent programming model for building applications and provides a separation between the user interface and the business logic. WPF leverages XAML, which is a declarative markup language. XAML stands for eXtensible Application Markup Language, which is based on XML. XAML is designed as a more efficient method of developing application user interfaces
ITS ABOUT MULTIPLE DOCUMENT WINDOWS AND FLOATING TOOL WINDOWS
Visual Studio was written to support multiple document windows and floating tool windows.
GREAT LIBRARIES ARE AVAILABLE
Codeplex provides a library to model the multiple document windows.
http://wpfmdi.codeplex.com/
There is also a docking library you can leverage:
http://avalondock.codeplex.com/
MEF IS USED HEAVILY
The internals have been redesigned using Managed Extensibility Framework (MEF).
MEF allows application developers to discover and use extensions without messing around with configuration files.
MEF allows you to easily encapsulate code and avoid fragile hard dependencies.
This allows developers to create add-ins to modify the behavior of the IDE.
DESIGN GOALS
In Visual Studio 2012, a one change is that the interface uses of all-caps menu bar.
Some design goals include reduced clutter and visual complexity by removing excessive lines and gradients in the UX.
The UI has been modernized by removing outdated 3D bevels.
You can take Spy++ which comes with Visual Studio and inspect the windows/class names of the application. If you do it with VS 2008, it's obvious that it's MFC. If you do it with VS 2010 and later, you will see that it's all WPF stuff--no MFC involved.
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.
I tried to search but if this is a duplicate it is hidden by some noise. Alternate title to the question:
What skills to look for when needing integration with the Visual Studio IDE?
Visual Studio 2008 is written in both native and managed code, though the bulk is written in C++. There are several pieces of Visual Studio that have always been written in managed code (e.g. the property browser, the WinForms Designer). And of course, Visual Studio 2008 is stitched together with COM.
In Visual Studio 2010, there is an effort to move more of the IDE to managed code. The text editor and the shell (i.e., menus, toolbars, document and tool window frames, etc.) are written in C#. In addition, pieces of the C# and VB IDEs are being written in C# and VB respectively. The new language, F#, is written completely in managed code -- the compiler, the language service, the project system, etc. -- are all written in F#.
You can use C#, VB or C++ to integrate with Visual Studio 2008. However, given that Visual Studio is built on COM, a good understanding of COM/ATL will be helpful. In addition, if you choose to use a managed language, a knownledge of COM interop and mixed-mode debugging will be extremely helpful. Note that there are a few levels of VS integration:
Macros -- the simplest way to run custom code in the IDE.
Add-in -- A simple but powerful way to build custom functionality into the IDE. With an add-in, you can create custom commands, listen to events, manipulate text in the editor, etc. However, you cannot add, say, a new language or editor to the IDE with an add-in. For many purposes, an add-in works fine.
Package -- this is the same level of integration as Microsoft's features use. With a package, you can create pretty much anything in the Visual Studio IDE, including adding new languages.
You should note that these become progressively more complex to author and deploy.
In Visual Studio 2010, a new form of extensibility is being introduced in several areas of the IDE, but primarily for extending the new WPF text editor. Going forward, integration with Visual Studio will require MEF (Managed Extensibility Framework) components rather than COM. So, in VS 2010, extending the text editor will simply require authoring a MEF component in your favorite managed language.
The podcast Herding Code episode #48 features an interview with Dustin Campbell, a program manager on the Visual Studio Managed Languages Group.
In that interview he talks for several minutes about this exact issue and gets into details about why the changes in 2010 are breaking compat with 2008 and how the future looks.
If this is strictly a curiousity question the other answers are correct. But if you want to dig a little deeper, listening to the podcast would be well worth your time.
At least the following languages are used inside of Visual Studio 2008
C++
C#
VB.Net
C
C++/CLI
C++ with managed extensions
Probably a few others that I forgot about.
A mix. The core is C++/COM stuff, but a lot of the newer stuff is managed code (C# etc). Due to the core being C++/COM (with a pile of code 'borrowed' from MS Office), VS integration is a funny experience.
If anyone knows how much of Visual Studio is turning into managed code?
I read in some sites that most of the Visual Studio 2010 is managed, compared to older versions where it was mostly native.
Is MS finally showing some premise for writing their first line of business apps with C# and .NET? (Thus proving that .NET is more than capable for doing large scale performant applications)
Actually in 2010 a lot of it is managed.
As mentioned above, the editor is fully managed.
The new shell (UI, toolbars, documents, menus, some toolwindows) is managed.
A good chunk of the language services (C#, VB) is managed.
All new C# and VB IDE features are managed (Call Hierarchy, Highlight References, Navigate To, Generate - From Usage).
Most (if not all) of F# is managed.
The build system (MSBuild) is managed.
A big chunk of debugger is managed (toolwindows, exception assistant, data tips, etc).
Most of Team System features (team test, team data, etc) is managed.
The entire TFS (Team Foundation Server - source control, bug tracking, builds, documents, etc) - is all managed.
ASP.NET and tools is managed.
Windows Forms designer is managed.
WPF and Silverlight designers are managed.
Various designers (such as resource) are managed.
The XML editor and XSD features are all managed.
IntelliTrace (back-in-time debugger) is managed.
Parallel Tools (parallel extensions) are managed.
A lot of other functionality which I can't now remember is surely managed.
And last, but not least, the About Box is now managed!
So I guess the question should be what's still native ;)
The code editor is now based on WPF in VS 2010. That alone gives us the ability to easily create new plugins in a way not possible under the old COM model.
For me the most interesting part is the new WPF-based editor. But it buggy and a bit slow even in Beta2. But If Microsoft sort out this performance problems i'll be happy. Because from VS2010 we can have strong confidence in .NET (since microsoft as the creator have confidence in .NET)
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).