Re: How to "update" old .NET code to current versions - .NET (Core and Framework) Discussion Boards

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.

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 | :laugh:

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

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.

"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

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.

Many thanks to everyone's input, I will try a "clean" build as recommended and hopefully post results back up here for future reference.

Pound to fit, paint to match

I wrote an app in Win Forms, and I'm using a circle in ListView, as a pleasant indicator. On my rigs, running Win 10 at home and 11 at the office, the ⬤ char works no problem. But on the customers computers running Win 7, I get the tall square symbol.

So I changed the Font in my Win Forms App to Segoe UI, which looks nice, but I still get the tall rectangle. I checked the customers computers to see what fonts are loaded, and Segoe UI is there.

Then I did research, and a few online posts talk about font searching by the OS, which dates back to Windows XP. If the Char ⬤ doesn't exists in the Font file, the OS will search for that char in other font files, such as webdings.ttf. Found a post about using the RegEdit /LocalMachine/Software/WindowsNt/Fonts and having to edit font mappings, which looked complicated.

ChatGpt says that I can MeasureText, to see if a char exists, and if not choose another char sysmbol.But the char always exists.

Dim font As New Font("Segoe UI", 9, FontStyle.Regular)

' The character you want to check (e.g., the copyright symbol ©)
Dim specialChar As Char = "⬤"

' Check if the font can display the character
Dim canDisplayChar As Boolean = TextRenderer.MeasureText(specialChar, font).Width > 0
If canDisplayChar Then
    Return "⬤"
Else
    Return "X"
End If

I'm just wondering if someone here has figured this out, and can share what they did. The customer really wants the ⬤.

On a side note or question, I can set a color for the circle in ListView on .Net Core 7, but can't set the color of the circle in .Net Framework 4.6.1.