Develop Reference

Is a .NET Standard DLL binary compatible with a .NET Framework one?

I currently have a utilities library built as .NET Framework 4.6.1 and referenced by various .NET Framework applications.
I now want to create a new .NET Core application and therefore I want to convert the utilities library to .NET Standard 2.0 so that it can be used by applications of both types.
If I simply open the source code for the library, change the target to .NET Standard 2.0 and rebuild it (assuming that it does only use APIs available in .NET Standard), can I just drop the new assembly in to replace the existing one and should the existing applications still work? Or would the applications need to be rebuilt against the new version?
And the more general related question is, what are the differences in the metadata produced for a .NET Standard DLL compared to a .NET Framework one, and how/if do they affect the assembly resolver?
(to pre-empt the comment "why not just try it and see", I want to know if this is a supported scenario, not just whether technically it might work for me)

.Net Standard is a compatible cross-section between (but not limited to) .Net Framework and .Net Core
Think of it like this
Or, one of the more standard propaganda pictures
There are lot of things in .Net Framework that just doesn't make a lot of sense in .Net Core. Windows specific things for instance.
However, what you can do is use The .NET Portability Analyzer to work out any glaring compatibility problems
Want to make your libraries multi-platform? Want to see how much work
is required to make your application compatible with other .NET
implementations and profiles, including .NET Core, .NET Standard, UWP,
and Xamarin for iOS, Android, and Mac? The .NET Portability Analyzer
is a tool that provides you with a detailed report on how flexible
your program is across .NET implementations by analyzing assemblies.
The Portability Analyzer is offered as a Visual Studio Extension and
as a console app.
And here is another picture (of the tool), because it makes my post look detailed
To answer your question
If I simply open the source code for the library, change the target to
.NET Standard 2.0 and rebuild it, can I just drop the new assembly in
to replace the existing one and should the existing applications still
work? Or would the applications need to be rebuilt against the new
version?
Needs to be rebuilt as far as i know, try it see what happens and let us know.
There are so many things that could make this not work.
And the more general related question is, what are the differences in
the metadata produced for a .NET Standard DLL compared to a .NET
Framework one, and how/if do they affect the assembly resolver?
Not entirely sure what you mean, however it will resolve just the same when rebuilt.
(to pre-empt the comment "why not just try it and see", I want to know
if this is a supported scenario, not just whether technically it might
work for me)
Just replacing the assembly is not supported as far as i know or could research. However maybe someone else has more information here.

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.

Targeting .NET Framework 4 when Framework 4.5 is installed

I have VS2010 and VS2012 installed on my computer and had the .NET Framework 4.0 which I then upgraded to .NET Framework 4.5. However, I am still developing apps that need to work on .NET Framework 4.0. The project says that it is targeting .NET Framework 4 (Client Profile) the assemblies even point to .NET Framework 4.0 folder under Referenced Assemblies. The problem comes when I move this application to a machine that only has 4.0 it won't start and come up with errors the immediate problem being an exception resulting from WindowState={Binding WindowState} which you can't do in 4.0 but you can in 4.5. I need this to throw the exception on my development box, why doesn't it? My assumption is that despite my best efforts is that it uses the 4.5 dlls if they exist. How can I make it really use 4.0 without uninstall 4.5?
Update
To repro this install .NET Framework 4.5 and create a WPF project targeting .NET Framework 4.0. Bind the WindowState to a property in a VM or code behind make this property have a public get and private set. .NET Framework 4.5 handles this just fine even when Mode=TwoWay must ignore the set .NET Framework 4 doesn't and throws an exception: "A TwoWay or OneWayToSource binding cannot work on the read-only property 'State' of type...". On the box with .NET Framework 4.5 works like a charm try it on a machine with only .NET Framework 4.0 and it blows up... So any ideas on how to really target 4.0 when 4.5 is installed?
Bug report to MS here: https://connect.microsoft.com/VisualStudio/feedback/details/774694/targeting-net-framework-4-0-when-4-5-doesnt-seem-to-work

Time to punt this question. I'm no expert on WPF, don't like it much for exactly these kind of problems, debugging dependency property problems is a nightmare. But I'm pretty convinced you are chasing a ghost. WindowState has been a dependency property all the way back to 3.0, nothing special happened to it in 4.5 that I can see or ever heard of.
You got some kind of error message that nobody can see that convinced you that it had something to do with the binding. I'm from Missouri, the Show Me State. Well, close enough to Wisconsin.
Spend more time working on code that gives you a reliable exception message and stack trace that helps you diagnose errors on the machine you deploy to, the one without a debugger to help you figure out what's going wrong. You do so by writing an event handler for the AppDomain.CurrentDomain.UnhandledException event. Log or display the e.ExceptionObject.ToString() return value. It gives you the exception message and the Holy Stack Trace. If that doesn't help then update your question with what you saw.

This appears to be a bug in .NET Framework 4.5 and it should throw the exception but with .NET Framework 4.5 installed there is no way to have your application run on .NET framework 4.0 it will always use 4.5.
See this reported bug for more info:
http://connect.microsoft.com/VisualStudio/feedback/details/773682/wpf-property-with-private-setter-is-updated-by-a-twoway-binding

You said you can't reproduce this in a test project. So that implies that it may be something that should work fine in 4.0 right? You might have some combination of code that is crashing on a bug in 4.0, that was fixed in 4.5. When you target 4.0, you will only get warnings when you try to use API's/features that the compiler can determine are not supported in 4.0.
Something that should work in 4.0 may crashed due to some rarely seen bug, and then fixed in 4.5. When your 4.0 targeted app runs under 4.5 environment, it will be affected by bug fixes to features that existed in 4.0.
There may be an update for 4.0 that includes the bug fix, so as not to require 4.5 upgrade if users are adverse to that for some reason. So it might not even be a 4.5 change, but simply a coincidence that some users don't have all of the updates available for 4.0(which would have been cumulatively includes in your 4.5).
These kind of cases I've rarely encountered, but do happen sometimes and are the reason people who support desktop .NET applications are notorious for asking users to update there .NET framework as a first try at solving odd issues before spending time troubleshooting.
Sometimes the opposite occurs. Your code only works due to some bug or poor behavior of a .NET API, and later an update cleans this up, perhaps tightening security somewhere is the most often thing I've seen, and your code suddenly breaks due to a minor version update of .NET.

.Net 4.5 replaces .net 4.0 with new, same-named libraries, that actually have some fixes.
That's short answer.
Unlike earlier versions, updating .net 4 to 4.5 replaces files, instead of adding sided by side files.
Even if you have folder like this Windows/Microsoft.Net/Framework/v40/ ,
After update, there is a change in this folder.
Files are changed, some errors were handled in .net without developer's concern.
How to target 4.0 framework using .net 4.5 ?
I still don't know, but I'm still digging
Suggested read on this topic:
Scott Hanselman :
http://www.hanselman.com/blog/NETVersioningAndMultiTargetingNET45IsAnInplaceUpgradeToNET40.aspx
Rick Strahl:
http://weblog.west-wind.com/posts/2012/Mar/13/NET-45-is-an-inplace-replacement-for-NET-40
And similar problem, created by me:
https://stackoverflow.com/questions/26483168/errors-on-net-4-0-dont-appear-on-net-4-5

The solution:
I've got the same problem when installed VS2017 after VS2015: Framework 4.0 just disappeared from project target list.
Following some comments around here I've tried with NuGet package: Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.4 and bin fix for 1.0.1.
Don't do that! My build time went ~300% up for the same project. It was disaster.
I see that 4.5 is an "in place replacement" for 4.0 However this does not explain why I cant see both options in my target frameworks combo.
I was reading the same mantra all around the web. It's simply not answer to the problem. Framework 4.0 is a must for any industrial machinery related software - because it runs on Windows XP, while .NET 4.5. is useless in my scenario, and probably for many other real-life stuff.
The solution is simple:
You just have to download and install Visual Studio 2013 Express from official web page:
https://www.microsoft.com/en-us/download/details.aspx?id=44914
After installing it, just open your VS2015 and you'll see 4.0 again.
...
"In place replacement ..." my....
This is re-post of answer I gave on a duplicate question. I'm posting here since this thread got more attention and existing answers here give no solution for the issue.

What does it really mean to target a framework, and how do I maximize compatibility?

Greetings all,
This has confused me ever since I first started coding in C#. My goal is to create an assembly that will run on the most recent .NET framework the user has, whatever that may be. I don't want to require .NET 4 to be installed, but I want to use it if the user has it, and more importantly, I want it to still work if the user has only .NET 4 and nothing below. I'm beginning to suspect this is not even possible.
I don't really understand what I'm selecting when I change the "Target Framework" in Visual Studio. Does that mean "will be compatible with this version and up"? Or "will be compatible with only this version"? It seems like it's the latter so far; my tests in virtual machines show .NET 4 targeted assemblies failing without .NET 4, and .NET 3.5 targeted assemblies failing without .NET 3.5. Is there no way to set this so I can achieve maximum compatibility?
UPDATE: To clarify, I have a program that targets .NET 2. The posters here seem to indicate that it should load with .NET 4. But in an environment with only .NET 4 and nothing before it, it fails to load.
UPDATE2: Okay, figured it out, but it's far more complex than the posters here seem to think. I'm opening a different question to discuss the intricacies, but the short version is, you need an app.config with <supportedRuntime version="v4.0" /> in it if you want to run non-.NET 4 assemblies on .NET 4. They won't load without it.

The frameworks are designed to be backwards-compatible; if you have a program written in .NET 2.0, you can run it in the 4.0 runtime, because none of the frameworks ever remove functionality that a prior version had (which is why we still have the non-generic collections like ArrayList, even though they're deprecated in favor of generic collections). However, the reverse is not necessarily true; a 4.0 app is not guaranteed to run in 2.0, because it MAY take advantage of new features of the new runtime that are not available in prior versions. In any case, if you want your app to attempt to run on runtime versions it does not specifically target, you must specify that in the app.config using SupportedRuntime elements.
To answer your specific question, you can do what you want with the following basic procedure:
Develop your app to target the EARLIEST framework version that you want to support. This will disable access to newer features of newer runtimes (like Linq in 3.5, and dynamic typing in 4.0) ensuring your app will not require any feature that cannot be provided by any of the supported runtimes.
Specify the frameworks that are acceptable to your application by using the SupportedRuntime element in your app.config file. This will tell the native code that initializes the runtime in which your app will run that if it can't find the targeted version, any of the others are acceptable. I believe the behavior is to look for the targeted framework first, and if not available it should use the newest supported runtime.

.NET is backward-compatible, this means if you select .NET Framework 2.0 as target framework, it will run on installed version 2.0, 3.0, 3.5 and 4.0.
But if you select e.g version 4.0 as target framework, it will only run if you have version 4.0 installed.

I believe this is supposed to be whatever version you select and upwards. So if you target 2.0 framework, it should work if client has 2.0, 3.0, 3.5, or 4.0 frameworks installed.
You are also selecting language features when you pick this, so I know of no way that you would be able to use 4.0 framework features using an application targeting 2.0 framework. Even dynamically loading assemblies doesn't work, try loading a dll compiled to 4.0 from a 2.0 application, it won't let you.

Here is how targeting works: If you target .NET 3.5, it will not run if user does not have .NET 3.5. It will run if user has any higher version.
For maximum compatibility, choose .NET 2.0, it will run even on .NET 3.5, 4.0 and so on.
However, you might loose out on new features of .NET such as LINQ etc.
http://msdn.microsoft.com/en-us/library/bb398197(VS.100).aspx
Can I still target .NET Framework 2.0 in VisualStudio 2010?

Problems executing compiled 3.5 code on a server which only has the 2.0 framework

I can't seem to get my application up and running on my dev server and I'm not sure why.
I have compiled my code in VS 2008 with a target framework of 3.5. I am using 3.5 mainly because I have implemented LINQ rather extensively. Compiling and runs local without any problems.
The hang up is that my server only has the 2.0 .Net framework and upgrading to 3.5 is apparently not going to happen.
I was under the impression after doing some research that as long as I was trying to execute compiled code the server would not need 3.5 installed.
Today I am trying to publish to the server and I can't get past this error in my WEB.CONFIG
Configuration Error
Parser Error Message: Child nodes not allowed.
providerOption name="CompilerVersion" value="v3.5"/
EDIT ADD ON QUESTION:
I have seen some posts about possibly setting my references to "copy local" which might allow me to run on the 2.0 server. Thoughts?

You are right in that 3.5 runs on the 2.0 CLR, but 3.5 contains libraries and if you have used any of those, you're out of luck unless you install 3.5 on that server.
There are plenty of options for a 3.5 program to not run correctly on only 2.0, so I'd consider downgrading the program, or upgrading the server.
Note regarding copy local. Even if you copy all the 3.5 libraries that your app uses, there is no guarantee it'll work and most likely it won't. Even so, distributing the libraries with your app is expressively prohibited by the .NET license.
Since you have stated you use LINQ, the only legal way to get your app running is to install the 3.5 license.
Or, you can rewrite your app using only 2.0.

I'm pretty sure that LINQ is one of the things that makes 3.5 a requirement. A lot of the other things, like lambda expressions etc. are just compiler trickery.
Because System.Linq is a 3.5 feature, the framework is required to be that version.
A good way to determine would be to change the target framework to 2.0 and see if it builds.

Code compiled against 3.0 or 3.5 may run on the 2.0 framework, but only if you do not use any libraries that are specific to the 3.0+ framework. One good way to find what's causing your code to fail is to switch your target to 2.0 and change things so that it compiles. Since one of your target installations is .NET 2.0, you are going to have to write .NET 2.0 code; this is not unique to .NET. In the past, writing an application that executed in both Win95 and WinNT involved extra work for the developer to carefully make sure the appropriate API was used.
Technically, 3.5-targetted code can run on 2.0 with no problems, but there's some gotchas you have to watch for. If anything accesses something that is unavailable in .NET 2.0, that will fail. This doesn't happen when the application starts, it happens when the application tries to make the call. I tested this by making a console application that does a little bit of output, then tries to display a WPF window. The output is made, but the application throws an exception when it tries to display the window on a machine with nothing but .NET 2.0.
Another gotcha is that VS 2008 actually comes with the .NET Framework 2.0 SP1, and there are a few types and methods in SP1 that are not in the normal 2.0 Framework. Visual Studio will not flag these methods as unsafe.
Finally, if this is a web application, the default web.config file for 3.5-targeted projects is very different than the web.config file for 2.0-targeted projects. Make sure you're distributing a compatible web.config. This is likely the problem you are encountering. A cheap workaround might be to change your target to .NET 2.0, copy that web.config, and use it in this case. Keep in mind that if you are using any 3.0+-specific language features or types your code will still fail, but this should get you past the web.config.

You're not going to be able to run code targetted to 3.5 on the server unless you get 3.5 installed on it.
The problem isn't your code, rather that the required libraries will be missing.

This is not possible. Although the CLR has not changed (like it did between v1.1 and v2.0) The libraries have. You cannot run a 3.5 app that doesn't have the 3.5 fraework installed. All of the Linq features are made possible by the 3.5 framework.

One error is in Web.Config. The published Web.Config is setup to allow compilation from .NET 3.5, which is the reason it includes build provider information.
Beyond that, your code won't run. By using LINQ, you're referencing assemblies that don't exist in .NET 2.0.

I was just going to leave a comment by my rep is not quite there. I agree with the crowd so far and believe that lassevk's answer is the best so please give him the rep for that. One this I wanted you to know about though is that once you install 3.5 on your IIS server (6 or better). When you go to the IIS Manager and right click on your website to access the ASP.Net tab. You will see AFTER the install of the 3.5 Framework that there is no 3.5 option available. It will still show it as 2.0.50727. Don't worry about that, it will still work just fine. Because of this inconsistence (thanks Microsoft) some confusion has been caused. Actually I think this is why you may have thought that 2.0 would run your 3.5 code just fine. Hope this helps and anyone please edit this so it makes more sense.

You can may use of some C# 3 features whilst targeting .NET 2.0. Its the language features which by the time its compilied to IL will run on the 2.0 CLR regardless of whether that CLR is part of a 2.0 or higher framework install.
Hence you can use anonymous types, extension methods and Lambda expressions but as soon as you do things like LINQ you then need external libraries that are part of 3.5
If you are only doing LINQ to Object you could add the LINQBridge to your distribution.
Another problem you can run into is if you are shipping a web application that includes the source code, such as code behind files, in line code and .cs in the App_Code folder.
You can end up shipping C# source code which compiles on the developement machine with C# 3 compilier present but fails to compile on a server only equiped with C# 2. In this case you can't use any new language features either.
What's worse is that specifing the .NET 2.0 framework as the target in the Visual Studio doesn't stop you using C# 3 language features. You get no warnings that such syntax will not compile on a 2.0 machine.
Hence if you are shipping such a web app, you'll need to compile pretty much everything first.

You can just copy over the 3.5 dlls onto the server. You can absolutely run 3.5 code on a 2.0 server.