.Net 4.0 targeting on windows 8.x - c#

I'm a bit confused about targeting .net 4.0 app to run on windows 8.x. In my understanding, windows 8.0 comes with 4.5 and windows 8.1 comes with 4.5.1. So my question, if I build a WinForms or WPF client app targeting c#/.net 4.0 (in Visual Studio Project settings) and of course only using .net 4.0 features (i.e, no features from .net 4.5.x), then will this app run fine on windows 8.x without having install .net 4.0 framework (that is, only relying on what comes installed with OS)? Basically, I'm trying to avoid forcing end user to install .net 4.0 framework on their machine before running the app.
Looking at DLLs properties of various Microsoft DLLs (e.g., System) they show same runtime version when targeting either .net 4.0 or .net 4.5.x --> v4.0.30319. So my understanding here is that 4.0 and 4.5.x are targeting same clr runtime version So, my .net 4.0 app should run fine???
From ref here (http://msdn.microsoft.com/en-us/library/bb822049%28v=vs.110%29.aspx), it says .net 4.0 can't even be installed on win8.x.
In my tests, targeting .net 4.0 and running on clean install of win8.1 seems to work fine (without having to install anything else) but looking for advice on gotchas.
Thanks.

Note that the .NET framework is intrinsically backwards compatible - .NET 4.5 will execute .NET 4.0 code just fine. This can be seen even within a solution in that a .NET 4.5/4.5.1 project can reference an older .NET project without incident. This includes .NET 4.0, as well as earlier versions.
In addition to the backwards compatibility, .NET 4.5 does run on the CLR 4.0 - 4.5 is simply a library and compiler expansion.
Possible gotchas
This emphasis on backwards compatibility is why we almost never see functions disappear from the .NET Framework, just get marked [Obsolete]. it's a good idea to check if any functions you use have become Obsolete, though this is rare and such functions usually continue to work as expected.
Windows 8 does NOT like Drive mapping, and will demand that you use UNC paths if you application touches any networks drives.
Windows 8 can be far more aggressive with requiring Admin privileges to run, up to and including needing to explicitly start VS as admin when trying to compile a program which outputs to C:\Program Files\...
Final note: ALWAYS test your application on the targeted platform before releasing to users.

Per this question:
.NET Framework 4.5 was released on 15 August 2012., a set of new or improved features were added into this version. The .NET Framework 4.5 is only supported on Windows Vista or later. The .NET Framework 4.5 uses Common Language Runtime 4.0, with some additional runtime features.
I would say then that by virtue of having .NET 4.5 installed you will also always have .NET 4.0 installed. I don't think this should be an issue then!

From the link you posted:
Each new version of the .NET Framework retains features from the previous versions and adds new features.
Also from that link:
The .NET Framework 4.5 is an in-place update that replaces the .NET Framework 4 on your computer, and similiarly, the .NET Framework 4.5.1 4.5.2, and 4.6 Preview are in-place updates to the .NET Framework 4.5, which means that they use the same runtime version, but the assembly versions are updated and include new types and members.
So, if a system has 4.5, it will be able to run apps targeted for 4.0 as well. The fact that some versions cannot be installed most likely only means that they are already included from the start.

Related

Target.NET framework version vs .NET framework version installed

We have a C# project and in Visual Studio the according "Target framework" is currently set to ".NET Framework 4.5". We have a second client library (written in C++) that calls this C# library to do something. For some new features we want to use the framework 4.6.1+. But we don't worn that C# project directly.
So some question in mind:
Generally, if we upgrade "Target framework" to .NET Framework 4.6.1 and on the machines where our app is running the actual framework is pre 4.6.1 (e.g., 4.5). What will happen? Will it throw some exception when the app is started?
If we stick to .NET Framework 4.5 as the target version, is there an option to automatically use the latest version actually installed on the machine where the app is run?
Thanks.
on the machines where our app is running the actual framework is pre 4.6.1 (e.g., 4.5). What will happen? Will it throw some exception when the app is started?
It will not throw an exception when the app started... The only time it could throw an exception is if (and when) your library calls a method that exists in .NET 4.6.1 but does not exist in .NET 4.5... You will get a MissingMethodException, other than that everything should work fine.
Something you can do is inspect what is the .NET Framework that is being run in the process that loaded your library.
string version = AppDomain.CurrentDomain.SetupInformation.TargetFrameworkName;
You can do that at the very start of the method being called in the library. And if the .NET Framework is < 4.6.1 you can decide what to do... Show an error message, or change the behavior as to not call into some functions (and avoid MissingMethodException).
One more thing you can also do determine which .NET Framework versions are installed on the machine and make some decisions on what to do.
.NET Framework 4.5+ is backward compatible. If app will be 4.6.1, but OS will have 4.5 then application error is possible (no forward compatibility). Documentation about version compatibility says:
By default, an app runs on the version of .NET Framework that it was
built for. If that version isn't present and the app configuration
file doesn't define supported versions, a .NET Framework
initialization error may occur. In this case, the attempt to run the
app will fail.

Can you launch a app C# so it doesn't need the .NET and you don't downgrade the .NET version

I asked this before but if i downgrade to .NET 3.5 I am not able to do some things with the windows form application I get errors because some things that have been added in later versions are not in the version that I am using.
I am making the application for Windows 7.
Link to previous: Can you launch a app C# so it doesn't need the .NET
As C# is essentialy a human-readable version of .NET's intermediate language (IL) you cannot run an application created using C# without .NET runtime installed.
You don't need to downgrade anything - just change target version to 3.5. However, you'll have to stick to features of 3.5 and below in that case.
If you want to use 4.0+ - just make an installer for your app which installs .NET 4.0 runtime alongside.
P.S.
I personally really doubt that there is noticable count of boxes running Windows 7 without at least .NET 4.0.
Just include the required Framework for your application in the Installer. They should be able to run side-by-side.

How to have two project in .net solution one targeting 4.0 framework and other one 4.5 framework?

I have a module which is using .Net 4.5 features and our application works for XP users also. So I was thinking of moving this .net 4.5 dependent module to separate project. How can I have a solution which is having two projects targeting to different version?
Each project in a solution is targeting it's specific version of .NET, so there is nothing special to that, BUT you can NOT reference that project/module targeting .NET 4.5 from the .NET 4.0 project.
If you need to target .NET 4.5 for some module your main application must also target .NET 4.5, so if there is no way around that features you need to ditch XP support, which is IMO not a bad thing as XP is not a supported OS anymore.
IF that feature from .NET 4.5 is the async/await-feature you could use the Microsoft.Bcl.Async-package an keep targeting .NET 4.0...

Reference a .net framework 4.5.1 assembly in a 4.0 project

How can i make a 4.0 project have a 4.5 reference. In the unit tests, i cant build the solution and it's giving me this warning.
Warning 2 The primary reference "PR.Wallet" could not be resolved
because it was built against the ".NETFramework,Version=v4.5.1"
framework. This is a higher version than the currently targeted
framework ".NETFramework,Version=v4.0". PR.Wallet.Tests
.Net frameworks (v2.0 or higher) are not forward compatible. . You can't reference a .Net 4.5 assembly in .Net 4.0 project.
See: Version Compatibility in the .NET Framework
You may also see: Version Compatibility
The degree of .NET Framework support for backward and forward
compatibility is version-specific. The .NET Framework supports both
backward and forward compatibility for applications created using
version 1.1 only. It does not support forward compatibility in
applications created using version 2.0. In the context of the .NET
Framework, backward compatibility means that an application created
using an early version of the .NET Framework will run on a later
version. Conversely, forward compatibility means that an application
created using a later version of the .NET Framework will run on an
earlier version.
The .NET Framework provides a high degree of support
for backward compatibility. For example, most applications created
using version 1.0 will run on version 1.1 and applications using
version 1.1 will run on version 2.0. The .NET Framework also supports
forward compatibility for version 1.1 only. However, for forward
compatibility you might need to modify an application so that the
application runs as expected. Applications created with version 2.0
will not run on earlier versions of the .NET Framework. For both
backward and forward compatibility, a change to the .NET Framework
that helps improve security, correctness, or functionality might also
raise compatibility issues.
Sounds like you need to change the framework of the library. And since it is only a unit tests project, I don't see why you wouldn't.
In Visual Studio:
Right-click on your project
Select Properties
Select the Application tab
Change the Target Framework to the desired framework
If you are not seeing .NET Framework 4.5.1 as an option there, ensure you have it installed.
You aren't able to reference a 4.5.1 assembly in a project that targets 4.0 .
But ... you can call the method of a 4.5.1 assembly in a project that targets 4.0 by calling it dynamically, assuming 4.5.1 is installed:
var assembly= Assembly.LoadFrom(...);
var type = assembly.GetType(...);
var method = type.GetMethod(...);
var res = method.Invoke(null, args);
Note that there may be limitations to this approach, but I found it useful for calling Roslyn routines while still using VS2010.
There may be exceptions. Based on my own experience, for example, some libraries like TagLib-Sharp 2.2.0 (which you can download from NuGet) perfectly allowed me to reference its .NET 4.5 DLL just fine from .NET 4.0 (Client of Full Profile) project running on Visual Studio 2010.
Additionally, calling some method from aforementioned referenced .NET 4.5 DLL did not emit any warning or error, build process went fine though, including at runtime. However, some methods/functions have failed, so it's a hit and miss but remember that referencing .NET 4.5 DLL was succeeded. So the answers and general rules above about "forward compatability" context clearly have some exceptions like TagLib-Sharp under particular circumstances.

Deploying a .net 4.0 application

I have an application built with .net 4.0 and uses WPF
My users have Windows 7 with default .net 3.5 installed.
My application cannot be downgraded to .net 3.5 and I want to avoid users from going through the process of downloading and installing .net 4.0 which is about 40MB (Even with silent install).
Since my application is a small one, is there a way to deploy it with only the required .net 4.0 libraries? and thus avoiding the installation of the entire .net 4.0 framework
If this is not possible, is there a way to execute the .net 4.0 app in a .net 3.5 environment?
If this is not possible, is there a way to execute the .net 4.0 app in a .net 3.5 environment?
No. Basically you really need to get the environments aligned. You say your application cannot be downgraded to .NET 3.5 - presumably that's because you're using something which is specific to .NET 4.0. It stands to reason that you can't then execute that in an environment which doesn't have .NET 4.0.
You need to decide which is more painful - changing your app to target .NET 3.5, or asking your users to install .NET 4.0.

Categories

Resources