How to "update" old .NET code to current versions
-
Lets start off with a little honesty - I am unsure of exactly what I am asking, but I am sure that someone can help. So I currently have Visual Studio 17.8 installed. I predominantly work in VB.NET. I have some older code downloaded from Github, that works just fine (as binary) when it was put together say 10 or more years ago. The crux of the problem is that you (and by you, I mean me) cannot in some cases simply drop it into VS 17.8 without several errors. Therefore, the naïve question is - can anyone point to a good source of information that would guide me on how to "upgrade" older code to eliminate errors in compiling with the current versions of VS and .NET? THanks.
Pound to fit, paint to match
-
Lets start off with a little honesty - I am unsure of exactly what I am asking, but I am sure that someone can help. So I currently have Visual Studio 17.8 installed. I predominantly work in VB.NET. I have some older code downloaded from Github, that works just fine (as binary) when it was put together say 10 or more years ago. The crux of the problem is that you (and by you, I mean me) cannot in some cases simply drop it into VS 17.8 without several errors. Therefore, the naïve question is - can anyone point to a good source of information that would guide me on how to "upgrade" older code to eliminate errors in compiling with the current versions of VS and .NET? THanks.
Pound to fit, paint to match
I'm interested ... what is older VB.Net Code and what is newer Code ? I would say that your question isn't to answer without more and specific Info ...
-
Lets start off with a little honesty - I am unsure of exactly what I am asking, but I am sure that someone can help. So I currently have Visual Studio 17.8 installed. I predominantly work in VB.NET. I have some older code downloaded from Github, that works just fine (as binary) when it was put together say 10 or more years ago. The crux of the problem is that you (and by you, I mean me) cannot in some cases simply drop it into VS 17.8 without several errors. Therefore, the naïve question is - can anyone point to a good source of information that would guide me on how to "upgrade" older code to eliminate errors in compiling with the current versions of VS and .NET? THanks.
Pound to fit, paint to match
You make a copy of the project, and try and compile it; then you can catastrophize.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Lets start off with a little honesty - I am unsure of exactly what I am asking, but I am sure that someone can help. So I currently have Visual Studio 17.8 installed. I predominantly work in VB.NET. I have some older code downloaded from Github, that works just fine (as binary) when it was put together say 10 or more years ago. The crux of the problem is that you (and by you, I mean me) cannot in some cases simply drop it into VS 17.8 without several errors. Therefore, the naïve question is - can anyone point to a good source of information that would guide me on how to "upgrade" older code to eliminate errors in compiling with the current versions of VS and .NET? THanks.
Pound to fit, paint to match
lewist57 wrote:
cannot in some cases simply drop it into VS 17.8 without several errors
Without the code and the specific errors, its impossible to tell you what the problem is. At a guess, are you trying to open a project that targets a version of .NET / .NET Framework for which you haven't installed the relevant VS targeting pack?
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Lets start off with a little honesty - I am unsure of exactly what I am asking, but I am sure that someone can help. So I currently have Visual Studio 17.8 installed. I predominantly work in VB.NET. I have some older code downloaded from Github, that works just fine (as binary) when it was put together say 10 or more years ago. The crux of the problem is that you (and by you, I mean me) cannot in some cases simply drop it into VS 17.8 without several errors. Therefore, the naïve question is - can anyone point to a good source of information that would guide me on how to "upgrade" older code to eliminate errors in compiling with the current versions of VS and .NET? THanks.
Pound to fit, paint to match
-
Lets start off with a little honesty - I am unsure of exactly what I am asking, but I am sure that someone can help. So I currently have Visual Studio 17.8 installed. I predominantly work in VB.NET. I have some older code downloaded from Github, that works just fine (as binary) when it was put together say 10 or more years ago. The crux of the problem is that you (and by you, I mean me) cannot in some cases simply drop it into VS 17.8 without several errors. Therefore, the naïve question is - can anyone point to a good source of information that would guide me on how to "upgrade" older code to eliminate errors in compiling with the current versions of VS and .NET? THanks.
Pound to fit, paint to match
Ok, my previous post was a great example of how not to describe what I am looking for, mea culpa. To give a more concrete example: Fast Colored Textbox is available here on CodeProject, as well as Github. It was posted in 2014, and has a target framework of .NET Framework 3.5. With VS 2022 17.8.2 (as of yesterday), the default target framework is .NET 8.0. To clarify: evidently, even though I am sure that Microsoft works very hard to keep backward compatibility, the process of upgrading the program to .NET 8.0 is not trouble free. When you open the original files and start building, VS 2022 starts with a "One-way upgrade" conversion, and it says it successfully migrated. When you build the project, you get a dozen errors about "invalid RESX file". Now I have not dug into the errors per se, but the naïve question is what is the root cause of these errors? Is it: a) Just a matter of ensuring all supporting files are in a location that the compiler can work with, or b) You can't count on the "one way upgrade" to do everything for you, or c) There is code from 2008 - 2014 .NET 3.5 that is not compatible with .NET 8.0, or d) all of the above, or something else Of the three, it is item C that I am mainly concerned with. Hope this makes more sense than the original post. Thanks to all for input received to date. BTW: I mentioned that I work mainly in VB.NET as a nice way of saying I do not do programming for a living.
Pound to fit, paint to match
-
Ok, my previous post was a great example of how not to describe what I am looking for, mea culpa. To give a more concrete example: Fast Colored Textbox is available here on CodeProject, as well as Github. It was posted in 2014, and has a target framework of .NET Framework 3.5. With VS 2022 17.8.2 (as of yesterday), the default target framework is .NET 8.0. To clarify: evidently, even though I am sure that Microsoft works very hard to keep backward compatibility, the process of upgrading the program to .NET 8.0 is not trouble free. When you open the original files and start building, VS 2022 starts with a "One-way upgrade" conversion, and it says it successfully migrated. When you build the project, you get a dozen errors about "invalid RESX file". Now I have not dug into the errors per se, but the naïve question is what is the root cause of these errors? Is it: a) Just a matter of ensuring all supporting files are in a location that the compiler can work with, or b) You can't count on the "one way upgrade" to do everything for you, or c) There is code from 2008 - 2014 .NET 3.5 that is not compatible with .NET 8.0, or d) all of the above, or something else Of the three, it is item C that I am mainly concerned with. Hope this makes more sense than the original post. Thanks to all for input received to date. BTW: I mentioned that I work mainly in VB.NET as a nice way of saying I do not do programming for a living.
Pound to fit, paint to match
Well, apart from saying you got "invalid RESX file"., we still have no idea what the problem is. As it is the .resx file is an XMLschema attached to the project properties, so you could try deleting it and let Visual Studio try to rebuild it. Of course, that assumes you have safely kept the original.
-
Well, apart from saying you got "invalid RESX file"., we still have no idea what the problem is. As it is the .resx file is an XMLschema attached to the project properties, so you could try deleting it and let Visual Studio try to rebuild it. Of course, that assumes you have safely kept the original.
Thanks I will give that a try. To distill things down further: is it possible that code written 10+ years ago will have problems building under .NET 8.0 and will require re-writing the code to build successfully? Or is the one way upgrade system good at catching potential problems and resolving the changes to the code?
Pound to fit, paint to match
-
Thanks I will give that a try. To distill things down further: is it possible that code written 10+ years ago will have problems building under .NET 8.0 and will require re-writing the code to build successfully? Or is the one way upgrade system good at catching potential problems and resolving the changes to the code?
Pound to fit, paint to match
That is impossible to answer; the only way to find out is to try it. Make sure that any generated files are removed from the project first, so you only have the .sln, .csproj/.vbproj, and source files that you created. Then once you run the build you should quickly be able to see what needs manual intervention.
-
Ok, my previous post was a great example of how not to describe what I am looking for, mea culpa. To give a more concrete example: Fast Colored Textbox is available here on CodeProject, as well as Github. It was posted in 2014, and has a target framework of .NET Framework 3.5. With VS 2022 17.8.2 (as of yesterday), the default target framework is .NET 8.0. To clarify: evidently, even though I am sure that Microsoft works very hard to keep backward compatibility, the process of upgrading the program to .NET 8.0 is not trouble free. When you open the original files and start building, VS 2022 starts with a "One-way upgrade" conversion, and it says it successfully migrated. When you build the project, you get a dozen errors about "invalid RESX file". Now I have not dug into the errors per se, but the naïve question is what is the root cause of these errors? Is it: a) Just a matter of ensuring all supporting files are in a location that the compiler can work with, or b) You can't count on the "one way upgrade" to do everything for you, or c) There is code from 2008 - 2014 .NET 3.5 that is not compatible with .NET 8.0, or d) all of the above, or something else Of the three, it is item C that I am mainly concerned with. Hope this makes more sense than the original post. Thanks to all for input received to date. BTW: I mentioned that I work mainly in VB.NET as a nice way of saying I do not do programming for a living.
Pound to fit, paint to match
The solution and project file formats for older versions of Visual Studio changed dramatically over the years. You opening an old .NET 3.5 project in a newer Visual Studio requires conversion of the project files (*.vbproj) and related to the updated formats. This has nothing to do with .NET 8.0. If you got the code from GitHub - PavelTorgashov/FastColoredTextBox: Fast Colored TextBox for Syntax Highlighting. The text editor component for .NET.[^], that solution has two projects, that target two different .NET Framework versions. You need to have both framework versions installed, .NET Framework 2.0 and .NET Framework 3.5. Just Google for ".NET Framework download" to get them.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
Ok, my previous post was a great example of how not to describe what I am looking for, mea culpa. To give a more concrete example: Fast Colored Textbox is available here on CodeProject, as well as Github. It was posted in 2014, and has a target framework of .NET Framework 3.5. With VS 2022 17.8.2 (as of yesterday), the default target framework is .NET 8.0. To clarify: evidently, even though I am sure that Microsoft works very hard to keep backward compatibility, the process of upgrading the program to .NET 8.0 is not trouble free. When you open the original files and start building, VS 2022 starts with a "One-way upgrade" conversion, and it says it successfully migrated. When you build the project, you get a dozen errors about "invalid RESX file". Now I have not dug into the errors per se, but the naïve question is what is the root cause of these errors? Is it: a) Just a matter of ensuring all supporting files are in a location that the compiler can work with, or b) You can't count on the "one way upgrade" to do everything for you, or c) There is code from 2008 - 2014 .NET 3.5 that is not compatible with .NET 8.0, or d) all of the above, or something else Of the three, it is item C that I am mainly concerned with. Hope this makes more sense than the original post. Thanks to all for input received to date. BTW: I mentioned that I work mainly in VB.NET as a nice way of saying I do not do programming for a living.
Pound to fit, paint to match
lewist57 wrote:
I am sure that Microsoft works very hard to keep backward compatibility,
I suspect they don't work that hard. For starters the general idea in programming is if you do a major version upgrade then breaking changes are allowed. After that it is just a matter of deciding what one should break or not. But one also does things like decided what new features to add and, sometimes, if something should be redone just to make it 'better'. Then one also needs to throw in required security fixes. All of that leads to complexity. The more code involved the more complex it becomes. So I suspect that although some consideration is given to backward compatibility, if even considered it is not a driving force. But I would not fault Microsoft for that. Any company would deal with the same scope of problems.
-
Lets start off with a little honesty - I am unsure of exactly what I am asking, but I am sure that someone can help. So I currently have Visual Studio 17.8 installed. I predominantly work in VB.NET. I have some older code downloaded from Github, that works just fine (as binary) when it was put together say 10 or more years ago. The crux of the problem is that you (and by you, I mean me) cannot in some cases simply drop it into VS 17.8 without several errors. Therefore, the naïve question is - can anyone point to a good source of information that would guide me on how to "upgrade" older code to eliminate errors in compiling with the current versions of VS and .NET? THanks.
Pound to fit, paint to match
Steps to upgrade. Start with a fresh directory/folder. Do NOT attempt to work this in your existing application. Even if you want to be in there when you are done only move it there once it works. Ideally you should start with the Visual Studio version that the library was built with. Why? Because you first need to verify that you can build it at all with the closest approximation to an ideal environment. Myself I would do a 'clean' (the older VS) before moving on. If it doesn't build then you will need to figure that out first. Ideally there should be a way to test (unit tests) so if so run those. If tests are missing then it would probably be a good idea to at least create a basic test framework that can exercise some of the functionality. Now you take a snap shot - check the code into source control. This is your baseline - version 1. ------------------------------------------ Now start the new VS and attempt to load the solution. Given the dates I suspect it is going to modify the solution. If you are lucky this solution will still build and tests will run. If yes then check it in, version 2. Otherwise you might as well move on the next part immediately. ------------------------------------------ Most of the work is here. There are some project configuration values that probably need to be updated (different Net versions.) You can try compiling after that but expect it to fail. You will need to update the libraries. Plural because there will probably be more than one. Compile. Then start looking at the errors. And fix them. Breaking changes mean exactly that in that you might need to modify the code so it works with a newer version. This could require either no work or a substantial amount of work. Once the errors are gone you should take a look at the warnings too. Sometimes those warnings can represent functionality that isn't going to work. ---------------------------- The above is an ideal scenario. In a less than ideal scenario you would need to upgrade, completely, to an older version of VS first. So do all of the above. Then repeat with the newest version that you actually want.
-
Ok, my previous post was a great example of how not to describe what I am looking for, mea culpa. To give a more concrete example: Fast Colored Textbox is available here on CodeProject, as well as Github. It was posted in 2014, and has a target framework of .NET Framework 3.5. With VS 2022 17.8.2 (as of yesterday), the default target framework is .NET 8.0. To clarify: evidently, even though I am sure that Microsoft works very hard to keep backward compatibility, the process of upgrading the program to .NET 8.0 is not trouble free. When you open the original files and start building, VS 2022 starts with a "One-way upgrade" conversion, and it says it successfully migrated. When you build the project, you get a dozen errors about "invalid RESX file". Now I have not dug into the errors per se, but the naïve question is what is the root cause of these errors? Is it: a) Just a matter of ensuring all supporting files are in a location that the compiler can work with, or b) You can't count on the "one way upgrade" to do everything for you, or c) There is code from 2008 - 2014 .NET 3.5 that is not compatible with .NET 8.0, or d) all of the above, or something else Of the three, it is item C that I am mainly concerned with. Hope this makes more sense than the original post. Thanks to all for input received to date. BTW: I mentioned that I work mainly in VB.NET as a nice way of saying I do not do programming for a living.
Pound to fit, paint to match
"Resource" files always seem to be a challenge; but it's not a "code" thing. It's how they were created or referenced in the first place. I "compress" my resources and you can't (always) compress in one framework and expect it to works in another ("Framework" versus Standard versus UWP versus WPF). No "error message"; just "different" (wrong) results.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
That is impossible to answer; the only way to find out is to try it. Make sure that any generated files are removed from the project first, so you only have the .sln, .csproj/.vbproj, and source files that you created. Then once you run the build you should quickly be able to see what needs manual intervention.
Agree with this 100%. The longer and time consuming method but probably the best and safest method is to clean the project and just run the solution, then start adding items - dll's, files etc one by one and compile. If it loads, all fine, if it fails, look for a solution to why it failed. This way you will save yourself hours of debugging by pinpointing the actual cause of failure, once remedied, move to the next.
-
Agree with this 100%. The longer and time consuming method but probably the best and safest method is to clean the project and just run the solution, then start adding items - dll's, files etc one by one and compile. If it loads, all fine, if it fails, look for a solution to why it failed. This way you will save yourself hours of debugging by pinpointing the actual cause of failure, once remedied, move to the next.
-
I guess you and I have probably been through this process once or twice. I have a Powershell script that purges all the object files from my projects when upgrading Visual Studio.
Indeed, bump your head once and learn from it, bump it twice and there is no medicine for the pain... :laugh:
-
Steps to upgrade. Start with a fresh directory/folder. Do NOT attempt to work this in your existing application. Even if you want to be in there when you are done only move it there once it works. Ideally you should start with the Visual Studio version that the library was built with. Why? Because you first need to verify that you can build it at all with the closest approximation to an ideal environment. Myself I would do a 'clean' (the older VS) before moving on. If it doesn't build then you will need to figure that out first. Ideally there should be a way to test (unit tests) so if so run those. If tests are missing then it would probably be a good idea to at least create a basic test framework that can exercise some of the functionality. Now you take a snap shot - check the code into source control. This is your baseline - version 1. ------------------------------------------ Now start the new VS and attempt to load the solution. Given the dates I suspect it is going to modify the solution. If you are lucky this solution will still build and tests will run. If yes then check it in, version 2. Otherwise you might as well move on the next part immediately. ------------------------------------------ Most of the work is here. There are some project configuration values that probably need to be updated (different Net versions.) You can try compiling after that but expect it to fail. You will need to update the libraries. Plural because there will probably be more than one. Compile. Then start looking at the errors. And fix them. Breaking changes mean exactly that in that you might need to modify the code so it works with a newer version. This could require either no work or a substantial amount of work. Once the errors are gone you should take a look at the warnings too. Sometimes those warnings can represent functionality that isn't going to work. ---------------------------- The above is an ideal scenario. In a less than ideal scenario you would need to upgrade, completely, to an older version of VS first. So do all of the above. Then repeat with the newest version that you actually want.
