|
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 ...
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
It all depends on what the errors are. So you need to post a properly detailed question.
|
|
|
|
|
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
modified 1-Dec-23 9:47am.
|
|
|
|
|
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
|
|
|
|
|
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... 
|
|
|
|
|
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.
|
|
|
|
|
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.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
What you "see" depends on the font of your "IDE"; what shows up at run time, is another matter (when you use "strings" for characters). Try "character codes".
https://stackoverflow.com/questions/3144053/how-to-represent-unicode-character-in-vb-net-string-literal
"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
|
|
|
|
|
I had to think about that for a couple of minutes. So instead of blaming the OS, I should consider the code, and use a character code. I'll try that. Thanks!
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
That got complicated, and resulted in showing a "n"
Decided to use these chars in string form, and it works for now ❶❷ they are in Segoe UI
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
You said you wanted to use Segoe UI Symbol; which means that has to be the font specified in your "UI" when you use (hex) codes for "special" characters in that font.
The "symbol font" in fact contains numerous "black circles" of various sizes (or the same size). You can't just pick "any" black circle and expect it to show up in "any" font.
In my app, I mix all "4" Segoe fonts (MDL2, UI, Symbol, Emoji) at the same time and never have any issues: character code + font family.
"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
|
|
|
|
|
I get it now!
I selected the wrong font file, and can use Segoe UI Symbols, which has the large circle, and alphanumeric chars as well. So I don't have to compromise now, and can finish as planned. Realize my UI goal or vision.
So this font style and font file solves my issue and is the correct fix. And I should not depend on Windows or the OS to do font searching and swapping for me, because it's unreliable.
Wow, I put so much effort into trying to solve this and it was very hard. Thank you Gary for putting me on the right track, and pushing me to get it right and not compromise for something sub standard.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
You're welcome.
And the "black circles" aren't really "black"; that's the default "foreground" color; you can change it to any color you want. That applies that "all" characters.
If you want a different color for the background, it has to come from the object "behind" it. "Characters" have no background color you can set. Emoji is colored by default and you can't change that.
You can layer characters to "insert" a color into (say) a "hollow circle" with a "solid colored circle" behind it (so as not have to put another "background" behind). And you can rotate individual characters (e.g. pointing arrows)
"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
|
|
|
|
|
I was pretty excited and thought I had it all figured out, only to be proven wrong again, where I got ".." which is 2 dots. target computer is a Win 7 32 bit OS, My "Extras" app is targeted at Framework 4.6.1. I got the code from Charmap; U+2824 Black Large Circle. On my rig it works great.
With my other Win Forms app called "Simple BOL" using .Net Core 7 I think, I can change the forecolor of a ListView cell or column, and make red, black and green circles on my rig running Win 11 64. But on these Win 7 32 bit OS machines with the app in question called "Extras", no luck either. In fact on my machine with Extras, the forecolor for a target cell won't change colors either.
So another swing and a miss for strike 3 now, batter out. Well I still have plenty of innings left in the game, so I'll try again tomorrow.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
