I have the Microsoft .NET Framework v3.5 and was wondering, if I use a command in my program that came from v3 and then give the program to someone with like v1.1, will the command still work properly? And I mean just the program, not the project.
Printable View
I have the Microsoft .NET Framework v3.5 and was wondering, if I use a command in my program that came from v3 and then give the program to someone with like v1.1, will the command still work properly? And I mean just the program, not the project.
No, your app must run against the framework it was written for, or higher.
When running on a higher framework, there are chances of breaking changes, but MS tries to make these few between versions.
If you wrote your app in 3.5, the user needs 3.5
if you wrote your app in 2.0, the user needs 2.0, 3.0, or 3.5
etc...
Is there a way to disable all v1.0 commands and higher so that if you want your program to be available to people with lower versions of the Framework they can still run it without it crashing just because you used a function like Array.Max().
No, if you want an app to work in .NET 1.1, you would need to compile that code in VS 2003 as a .NET 1.1 application.
.NET 1.1 and 2.0 use totally different CLR versions.
.NET 3.0 and 3.5 are subsets of .NET 2.0 and still run on the .NET 2.0 CLR, which is why you see direct compatibility between these versions.
Also, the next version, .NET 4.0, is also a new CLR, however it supports side by side processes running different CLR versions in the same host process.
Is there an issue where a user can not install .NET 2.0 on a machine? It works on Windows 98 and up.
It's not that they can't, but it's impractical. I've made some simple programs that have become popular but the users shouldn't have to wait 1-3 hours for .NET 3.5 to download and install. And that's if they have 2.0, some computers only have v1, so its even longer to get the other versions.
And when its just a simple 50kb program, it seems like they would have to go through a lot just to get it to run.
Is there any simple way around this? I don't want to have to get vb 2003 just to make this program available to lower versions.
1-3 hours sounds pretty long to install the framework, even if it needs to be downloaded. It installs in at most 20 minutes on slow machines in my experience.
The download for .NET 3.5 SP1 is only 2.8 megs in size. From there it will intelligently download the rest. What that means is, if the user has .NET 2.0, it will only downloaded the needed parts to add .NET 3.5, if they don't have 2.0, it will download that as well. It only downloads what they need based on what they already have.
When I got .NET Framework ( don't remember if it was 2 or 3) I can swear it was over 200mgs...
Also I remember someone leaving feedback saying it took them hours to download it.
And one more thing. If I make a program in VB 2008 but use only commands available in framework 1 and 2, will it still run? Or does 2008 compile in a way such that it will only run on the same framework, even if the commands were all in previous ones.
Forget .NET 1.1, it has virtually no compatibility with .NET 2.0 except for the fact that a 1.1 app will run on NEWER frameworks like 2.0 and up (aside from the breaking changes I mentioned above)
As far as framework size goes, yes there is a giant download of certain .NET frameworks, but these are generally intended for network deployment scenarios. These giant framework setups usually contain multiple versions of the framework (x86, x64, IA64). When you have the user run the 2.8 meg download, its just going to go download what they need based on their actual computer.
And someone saying it took hours to download, even at 200 megs, they must be on dialup ;) 200 megs coming from Microsoft's servers I will have within minutes, I am on a cable connection here.
Starting with 2008, you can designate which framework, but only back to 2. Therefore, you can designate 2, 3, or 3.5. You're still out of luck as far as 1 and 1.1 users are concerned.
Sorry I didn't address this:Quote:
Originally Posted by Vectris
When you use VS 2008, and you make a new project, you have an option at the start to select the target framework version. You can select between 2.0, 3.0 and 3.5, again because they all run on the same CLR version. VS2008 was the first VS version to support multiple framework targetting.
You can toggle the framework version after the fact in the project properties as well, however you may need to manually fix some references at that point.
Ah, so if in VB 2008 I set it to 2.0 then it will restrict me to only 2.0 commands and thus run fine on computers with out the updates?
[/quote]You can toggle the framework version after the fact in the project properties as well, however you may need to manually fix some references at that point.[/quote]
What manually fixing references be? I'd rather change it in my program than copy and paste everything to a new project.
If you made an app in 3.5, and you didn't use anything that was new to 3.5 (aka would be available in 2.0) and you are using VS 2008, then go into the project properties, and then the compile tab.
Click the advanced compile options, and that screen will contain a drop down to change the framework version. Changing it to 2.0 will cause the project to be saved, closed, and reopened. At that point you may have some warnings or errors reporting.
Go back into the project properties, go to references, and delete any references showing version 0.0.0.0, and will also have <the system can not find the reference specified> or something like that where the file path/name would normally be.
Deleting those references should clear up the warnings. If you still have any about "project level imports" then on that same references page under the "Imported Namespaces" section, find the imported namespace that the warning lists, and uncheck it.
This may sound like a bunch of work, but should really take no longer than about a minute or so to complete.
Actually most of that was easy. The only problem is that I have that project-level Imports warning for System.Xml.Linq and when I double click it to uncheck it, it only stays unchecked for like 5 seconds and then it re-checks itself 0.o
Also another question. If I just take out the v3.5 specific commands then even though I have 3.5 and VB 2008 it should still work on 2.0 since right?
the checkboxes on that project level imports section act a bit weird.
You need to click the item once, which should highlight it, then once it is highlighted click the checkbox to uncheck it.
I think there is a delay when you uncheck it since the IDE has to go though the entire project and make sure everything still checks out properly. So you may be getting impatient with that delay, and clicking it again.
As far as your other question. If you target .NET 2.0, then yes, if it compiles it should work on .NET 2.0. Of course nothing beats actually testing things on clean hardware, but if you don't have access to do that, then you will have to just hope there are no issues ;)
By "target .NET 2.0" you don't mean literally change that setting in the program do you? I know that's a possibility but I've noticed that when I changed the program to 2.0 it runs a lot slower than the one that was set for 3.5 even though all of the commands are in 2.0. So I'd like to keep it set on 3.5 but not use any 2.0 material and still have it work.
I may be able to test it at a friends house but I already updated all of my computers to 3.5.
When you start a new project in Visual Studio, it will give you the option of targeting different frameworks. You can also change the targeted framework in the Project Properties, but if you are utilizing anything from, say 3.5, and you're targeting 2.0, it will give you an error in the code.
I know that but I'm double checking that if I specify 3.5 but only use code that will work in 2.0, then it will still work on 2.0 computers.Quote:
Originally Posted by weirddemon
No, it will not.Quote:
Originally Posted by Vectris
well that sucks X( I wish I could test all this myself though, I still will if I get the chance, thank you everyone for the responses though.
why specify 3.5 if you want it to run on 2.0?
How much slower did it really run, and did you really do accurate time tests?
Why, because 3.5 runs faster than 2.0.
In the program I was testing I have a funtion that loops through all the files in a folder, including sub folders, finds any .ini files, loops through the .ini text for 2 variables, then adds the variables to a listbox and adds the original path of the .ini to a list variable.
Anyways I have a medium sized directory of .inis to test it on and in 3.5 it takes about 3 seconds for the function to run. With 2.0 it's about 6-10 seconds.
It's not that bad for me but for some users who have several times more .inis than me, its a much larger deficit.
did you test these scenarios as release builds outside of Visual Studio? or were you doing all this testing running from the IDE?
Not sure about the terminology of IDE (I'm guessing you mean debugging it from the project files) but I did use the built .exe file.
did you also compile them in release mode?
Don't know what your talking about so probably not.
When you compile in release mode, the code is optimized for actual distribution. When you compile in debug mode (which is the default) you are leaving all kinds of extra debugging information in the compiled code.
Oh... so, how do I compile in release mode?
The easiest way to toggle is to add the "build" menu to the menus at the top of Visual Studio. Just right click in a blank area where those menu toolbars are, and find "build" in the list that comes up. You should then get a new menu on there that has a dropdown for debug/release modes.
You can also change it in the compile tab of the application properties.
Still not sure what to do, it has to Build options, "Build PROJECTNAME" and "Build Solution".
I tried both and it just says built.
Also, if by release you mean getting the .exe from the Release folder then yes I have done that by Pressing the Build button that is already in the toolbar. I found the Release to be even slower than before.