I have code for a software written in C++ with MFC in Visual Studio 2005. Now I need to migrate it to Visual Studio 2015. How can I do it and what are the challenges to be countered?
Like said in comments, open your solution, it will be converted. The issues I had when doing so:
Only blocking issue for compilation I had was to change the Unicode handling option in project options because one of the related options disapeared/changed its values. There is a report after the conversion is complete, read it!
All possible issues with such a huge gap in compilator versions are still possible then. So be carefull of the warnings (activate them if not done)
Running some code analysis may be a good idea to detect deprecated syntax/methods, I had some unexpected behaviour on old Microsoft methods that were a bit too permissive before (clearly it was my fault but for some reason the old compilator was kind with some of my mistakes).
Related
I have a program for Visual C++ that I would like to further develop on CLion. I have managed to make it compile fine, however code insights are still showing errors on a bunch of things. Foremost among them is certain type definitions not resolving correctly. I have traced them through to the original definitions from the AMD OpenCL SDK, however those definitions have errors:
As far as I can tell, the problem with those is that it thinks it's defining the __int8 types. I believe that __int8 and the rest are supposed to be defined in the Microsoft Visual Studio stuff, but I can't figure out how to link that into the project using CMake or CLion.
I'm using CLion 2017.2.3 and have Microsoft Visual Studio 2017 Community installed.
I suspect that I'm not understanding something with how Microsoft Visual Studio integration would work, but please let me know if there is any further useful information that I could provide.
EDIT:
I've done some further digging, and it looks like I must be missing something fairly major. The __int8 style types are apparently Windows only, but even size_t and FILE aren't defined according to the code insights.
That's a CLion bug. We are currently on it and it will be addressed in 2017.3 likely. Follow the updates here: https://youtrack.jetbrains.com/issue/CPP-9224
I have a couple of Projects created in visual basic 6 with oracle databases. I want to upgrade these proejects to visual studio 2012 and use TFS version control. I have read that first I need to upgrade to Visual studio 2008 and then to Visual studio 2012.
Before going ahead with the upgrade ( I need to install Visual studio 2008 as well) I want to make sure this is a realistic approach. So
1. Does converting a vb6 project to VS 2012 ok or I will have to make a lot of changes to make things work?
2. After upgradation would I be able to use TFS for the projects?
TL;DR - yes, you'll need to make lots of changes regardless of how you choose to migrate. TFS question seems irrelevant to me. If you're setup to use TFS for projects, you can use it for these after upgrade as well.
The only reason to consider a 2-step upgrade that includes VS 2008 is that was the last version that included the migration tool built-in (ie, free). As others alluded to, those tools don't make pretty code but a mashup of VB6 and .Net. After trying a few times, I now personally find it simpler and more robust to recreate a new .Net version from scratch, but using the VB6 code as a template. I copy and paste as practical and then do Find/Replace to catch the majority of errors/warnings and then deal with all the others individually. If I have to convert another project, I may use 2008 once just to see what kind of issues the original code had or if there are any unusual situations/controls I'll need to deal with, but I would still start a new 2013 project from scratch. That gives me a better opportunity to improve it as well. You'd be replacing all the connecting code to Oracle anyway. I'd been using OO4O and moved to ODP.NET. If you used 2008, you would have to move to at least 2010 to use the latter in managed mode, which is great not having to load Oracle Client on each machine.
I'd be wary of upgrading VB 6 to VB.net using the automated tools. I did it back in the day (around 2003) when .net was just starting out and my memory is that it wasn't a pleasant experience.
The code produced by the upgrade wizard is a nasty mix of old VB conventions trim, instr and .net conventions. We also had a bunch of weird bugs. Sorry it was a long time ago and I can't remember any details. Only that we did it once for a small number of components, around 6 or 7 activex dll's. That experience was bad enough that we decided it wasn't worth the pain.
We kept the VB 6 code in service until it was re-written as part of a larger push to modernise the codebase.
If you do decide to upgrade then the output is a standard visual studio project that can be source controlled in TFS just like any .net project.
If you reason for upgrading to just to use TFS then take a look at the MSSCCIProvider. This allows you at hook TFS in to the VB6 IDE
I am doing something very similar and did develop a tool to assist with the designer portion of the conversion. It parsers the VB6 file and creates designer code for .NET.
The source is here.
https://github.com/rdejournett/VBtoNET
The only thing I was not able to solve is that controls within tab pages have really wierd X locations like -60000. So I parse those to 0. You'll have to move them to the right place.
Hi I'm newer to this technology. And I also migrate the MFC project to visual studio 2008 which is developed in visual c++ 6.0. If its possible are not? I already start my work on that and face some issues like initialization of variables and inclusion of header files. And some cases it shows the CString error and template error. Can any one suggest its possible are not?
Thanks in advance.
It is very much possible. It may need a day or two to fix all compiler and linker errors. You will need to fix compiler errors, Unicode stuff, MFC related errors, some deprecated stuff, stricter C++, and many other. But, it is doable, and worth doing.
I'm using TypeScript in Visual Studio 2012 and when I have to refactor my code and must temporarily introduce a lot of errors visual studio become unresponsive for up to a minute, very often, making it impossible to refactor efficiently.
How can I turn this off temporarily until I feel like I've patched the majority of errors?
It shouldn't be that bad, else it's a bug. Unfortunately with the latest release there is an issue being investigated. See https://typescript.codeplex.com/workitem/779 . If it's not this issue, then please log another describing how to reproduce the issue you are seeing reliably, and it will get investigated.
There is a fix checked in for the above issue that is being tested currently (see https://typescript.codeplex.com/SourceControl/changeset/e44dbae94e04 ). If you are feeling lucky and don't want to wait for the next update, you could always replace this line of code yourself in the typescriptServices.js file and see if it resolves your issue.
See http://blogs.msdn.com/b/typescript/archive/2013/01/29/trying-the-latest-typescript-build.aspx for details on the location of the file to update.
I'm looking for the Pex Addin for VS 2012 (or its equivalent).
I know Moles became Fakes (http://msdn.microsoft.com/en-us/library/hh549175.aspx) which is present. I want the Pex part as input generator for automated WhiteBox testing. I'm not sure how I can do this within VS2012. Could someone give me a pointer here?
The Pex Team say that they're going to build a new release of Pex, but the simultaneous move from Moles to Fakes is causing 'some changes to how things work internally, and is delaying the next release of Pex'.
One of the contributors to this question got some information from Microsoft saying that they expect the academic licence to be available in early 2013.
Finally Pex has something for Visual Studio 2012: Code Digger (http://visualstudiogallery.msdn.microsoft.com/fb5badda-4ea3-4314-a723-a1975cbdabb4). You can ask it to generate a input / output table, with parameters that will cover all your code.
However, it supports only Portable Libraries projects today... let's wait for new releases.