Develop Reference

.net Dll shows framework 4.0 after being converted to 4.5.2

I've found a partial answer to my question in this thread:
Here on stackoverflow cannot change target framework...
In my case, the framework has successfully been converted to 4.5.2, and putting a method with async and await, that I'm sure are part of framework 4.5, the method is successfully run by an exe referencing the library. So I can presume that the library is really compiled using framework 4.5.2.
However, when referenced in any other project the library shows in its properties that it is compiled under framework 4.0. and when the debugger loads the assembly it prints out that it is compiled under framework 4.0...
So who is right? my code executing methods of framework 4.5 or the strings telling the library is on framework 4.0?
I've checked for what possible in my abilities if there are any .targets files in my installation, and yes there are two, under the msbuild-targets temporary folder, Microsoft.Common.targets and Microsoft.Csharp.targets, but I'm not able to understand if these files force the compiler to use framework 4.0.
Mainly because on this machine I compile directly in visual studio.
I have several solutions using component libraries compiled 4.5.2 that work correctly. So I don't really know how to be sure that my library is compiled under the right framework and that the library shows the right framework in its properties and when loaded.
If anyone has a clue on how to achieve this,
thank you in advance.

If your project properties say you're targeting .NET 4.5.2, then it's being built to work with .NET 4.5.2 and above versions.
Maybe you've a confusion with CLR and Framework versions. .NET 4.x (any) work with CLR (i.e. Common Language Runtime) 4.0.
Check .NET Framework Versions and Dependencies to get further details about this topic.

How to make an application compatible with .NET 4.0 and .NET 4.5

I'm pretty new to .NET and C#.
I recently took up the task of upgrading my application from .NET 4.0 to .NET 4.5 to keep up with other products in my team.
I would like to be able to run my application (which has several projects, some web projects based on ASP .NET and some standalone app projects (console application)) on .NET 4 and .NET 4.5.
After following instructions online regarding <supportedRuntime> Element to upgrade from .NET 4.0 to .NET 4.5 by changing the target run-time I realized that the compilation element's targetFramework attribute is now 4.5. I understand that this means the code will definitely work on .NET framework 4.5.
What if I have a set of nodes that are waiting for 4.5 upgrade which are still running .NET 4.0. I'm pretty sure that my changes would break the application.
So I did some research and after referring to some documentation online, I've removed the sku attribute from the supportedRuntime element in the *.config files of the projects in the solution. Though the version attribute of the supportedRuntime element is still v4.0 (CLR version). I hope this make the application run on both .NET framework 4.0 and 4.5.
But I don't really know much about the compilation element and its significance apart from what I read from ASP .NET configuration guidelines. Would leaving the targetFramework make sure that my applications work on both .NET 4.0 and .NET 4.5?
How can I make sure that my changes are compatible with both .NET 4.0 and .NET 4.5?
[Why not leave it as .NET 4.0 till the nodes have their .NET frameworks upgraded?]
You might wonder why I can't keep it as .NET 4.0 for now.
The aim is to upgrade to .NET 4.5. But the standalone script runs on a set of nodes that run on Windows Server 2003 that does not support .NET 4.5. I've got my system admin team to allocate another node with .NET 4.5 for this process alone. So for the time being I can't really completely upgrade my existing code. Until after I test my existing code on .NET 4.5 and configure deployment to those new nodes.
Thanks to that comment from #hvd which lit a bulb in my confused brain. Now I know how to proceed.

The versioning of the .NET Framework is distinct from the versioning of the runtime (CLR and jitter). Already the case in previous versions, .NET 2.0, 3.0, 3.5 and 3.5SP1 used runtime version v2.0.50727.
Much the same for the 4.0 branch, versions 4.0, 4.0.1, 4.0.2, 4.0.3, 4.5, 4.5.1 and 4.5.2 all use the same runtime version, v4.0.30319
The "sku" attribute was added to provide the CLR with an extra check to ensure that the correct framework version is present on the machine. And powers this feature, very desirable. Without it, your 4.5 targeted project will start just fine on a machine that only has 4.0 installed. But will tend to fall over on a pretty ugly runtime exception, usually caused by a missing type or method. Especially the changes in 4.5 were rather impactful, types were moved from one assembly to another to make the footprint of the framework smaller on portable devices. This question is a good example, very ugly to diagnose.
A good example of how this went wrong before is the EventWaitHandle.WaitOne(int) overload. Added in .NET 2.0SP2 (aka 3.5). A good idea, nobody knew how to use the WaitOne(int, bool) overload properly. But a breaking change without a corresponding change in the [AssemblyVersion] for mscorlib. Causing horrible problems, programmers used the overload with gusto but their programs failed when it ran on an older version of .NET. Kaboom with a MissingMethodException, leaving very little clue how a simple and common method could be missing.
Cold hard fact is that if you target 4.5 in your project and remove sku then you'll get to deal with this kind of misery. You have to target 4.0 to keep compatibility, very simple to do of course.

In fact, if you change framework version to 4.0 in project properties, you'll be sure that 4.5 assembly members (namespaces, classes, interfaces...) won't be visible during design time/development time. Or compiler will cry if you try to use a member from version 4.5.
This is possible the best way to be sure you're not going to use newer members not present in previous .NET Framework versions.

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.

Back port .NET 4 to 3.5 SP1 in VS2010

I wrote a simple VS2010 WPF application which targeted .NET Framework 4 Client Profile. (In fact, my app does not use any .NET 4 features, but VS2010 just by default started my project targeting .NET 4 so I didn't bother to check it)
I found all XP system and even a few Window 7 of various languages failed to start the app. I decided to back port my app to target .NET Framework 3.5 or .NET Framework 3.5 Client Profile, by changing the Target Framework in solution's properties. But the app does not compile or build with the following error on System.Xaml and Microsoft.CSharp:
Warning 1 Could not resolve assembly System.Xaml. The target framework required by this assembly (4.0) is higher than the project target framework. If this reference is required by your code, you may get compilation errors. test1
Warning 2 The primary reference "Microsoft.CSharp", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETFramework,Version=v3.5". To resolve this problem, either remove the reference "Microsoft.CSharp" or retarget your application to a framework version which contains "Microsoft.CSharp". test1
Warning 3 The referenced component 'Microsoft.CSharp' could not be found.
Warning 4 The referenced component 'System.Xaml' could not be found.
Is it possible to back port (or back target) a VS2010 app to .NET 3.5? If so, how?
[EDIT]
I found there was one Control - DataGrid - that is designed to use for .NET 4. I have to install WPF Tool Kit to back port the controls to 3.5. Hope someone find this helpful.

Just remove them. Tested it and works for me. I believe those assemblies were only introduced in .NET 4. The types in System.Xaml, for example, are defined some place else in .NET 3.5 (like PresentationCore for example). See this article for more info.

Remove these references altogether. If you still need them, re-add them through the UI in Visual Studio. You should see the 3.5 versions or 2.0 versions of those assemblies. By using those older versions, your app should compile.

You have to remove those references at the references folder and readd them with the 3.5 version.

Migrating from .NET 2.0 to .NET 4.0

What are the changes I need to make to a application built with .NET 2.0 /C# in order to use the C# 4.0 features . Recently I ran into a problem, when trying to add optional paramters in a product which was developed on .NET 2.0 / C# 2.0 .

Most 2.0 programs works without any changes on 4.0. It was only on 1.1 to 2.0 that there was a lot of incompatible changes.

One problem, that I ran into recently when upgrading a 3.5 project to 4.0 (Visual Studio 2008 to Visual Studio 2010), was that after upgrading to 4.0 I did not have a reference to System.Core and was unable to add it via Visual Studio instead displaying a message:
A reference to 'System.Core' could not be added. This component is already automatically referenced by the build system.
You will need to have a reference to System.Core if you want to use the var keyword and LINQ extension methods.
It can be manually added (or readded if removed). See the blog post System.Core in VS2010 Projects for details.

Maybe you migrated your Visual Studio solution to 2010, but you forgot to change the target framework to 4.0 in projects' properties.
Just go to properties in your solution projects (obviously, the migrated to Visual Studio 2010 solution) and change the target framework to 4.0.
That's all your C# code base will be using .NET Framework 4.0 and C# 4.0. I'm pretty sure you won't need to change your code, but, maybe, you'll find that some classes, methods, properties are now obsolete, but it'll compile anyway.
Comment out if you don't know how to do that.

In theory, C# 4 should be backwards compatible with C# 2.
In practice, I've done it several times with no problems, and I think the only obvious problem is if you have named some classes that are defined by the .net 4.0 framework.

You cannot use .NET 4.0 specific features in an application targeting .NET 2.0. You will need to migrate to .NET 4.0.

You can't easily convert form a higher version to a lower version.
You can easily convert form a lower version to a higher version.

C# in .NET 2.0 does not support optional parameters if I remember correctly.