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.
Related
I'm certain there's probably a bunch of things going on here that I don't understand well enough, so forgive me if this is a stupid question or if there's obvious details missing.
I have a Visual Studio 2015 solution that I've upgraded from .NET 4.5.1 to .NET 4.7.1. The solution consists of a website (not web app) project, and several libraries. The libraries don't really have any dependencies (except eachother) and while they are targeting .NET 4.7.1, they don't use, need, or reference .NETStandard.Library.
When I compile one of the libraries in particular, it keeps copying a bunch of .NET 4.7.1 facade dlls into the website bin folder. Unfortunately, the website is a Kentico 11 application, and it keeps trying to load the System.IO.Compression.ZipFile facade, and chokes on it because it's a reference assembly, not a real assembly.
If I delete the .dll, everything runs fine... but I don't want to delete it every time or add a post-build event to delete it. That's just silly.
Can anyone help me understand what's going on here, and how to clean it up?
Kentico 11 can only target up to .NET 4.7 so in an attempt to fully support your .NET 4.7.1 libraries I believe it is copying in those additional facade DLLs. This is based on the .NET 4.7.1 release announcement, specifically this section:
BCL – .NET Standard 2.0 Support
.NET Framework 4.7.1 has built-in support for .NET Standard 2.0. .NET Framework 4.7.1 adds about 200 missing APIs that were part of .NET Standard 2.0 but not actually implemented by .NET Framework 4.6.1, 4.6.2 or 4.7. You can refer to details on .NET Standard on .NET Standard Microsoft docs.
Applications that target .NET Framework 4.6.1 through 4.7 must deploy additional .NET Standard 2.0 support files in order to consume .NET Standard 2.0 libraries. This situation occurred because the .NET Standard 2.0 spec was finalized after .NET Framework 4.6.1 was released. .NET Framework 4.7.1 is the first .NET Framework release after .NET Standard 2.0, enabling us to provide comprehensive .NET Standard 2.0 support.
https://blogs.msdn.microsoft.com/dotnet/2017/10/17/announcing-the-net-framework-4-7-1/
Reference that led me to this conclusion:
https://github.com/Particular/NServiceBus/issues/5047#issuecomment-339096350
Update:
I was unable to reproduce your issue in Visual Studio 2017 Version 15.6.2.
I installed a Kentico 11 website project targeting .NET 4.7. I then created a library project that targeted .NET 4.7.1. I added some dummy code to the project to make use of Sysetem.IO.Compression and System.Net.Http namespaces. I added a reference to the project from Kentico and ran a build. No facade DLLs where copied to the bin folder.
This post indicates the issue was fixed in Visual Studio version 15.6 https://github.com/dotnet/sdk/issues/1647#issuecomment-364999962
The additional files that get deployed to your bin folder are needed to support referencing and running .NET Standard 1.x and .NET Standard 2.0 libraries in your .NET Framework application.
We have documented this as a known issues with .NET Framework 4.7.1.
The presence of those additional files is not sufficient however. You also need to have binding redirects generated in order to ensure types correctly unify across libraries.
Visual Studio 15.6.3 (and later) have a change that will automatically generate those binding redirects for your application.
.NET Framework 4.7.2 addresses the issues that require those additional files to be deployed with your application. When targeting or running on .NET Framework 4.7.2 you won't have any additional files copied to your bin folder and no binding redirects will be automatically generated.
You can try .NET Framework 4.7.2 and see what's new by following the instructions here.
References to assemblies have their own properties. You can specify there if you want to copy the assembly to the build output directory. Maybe somewhere it is set to true. To check that go to Solution Explorer in Visual Studio and right click on the referenced assembly. Then click Properties and look for property named "Copy Local".
In preparation for moving to VS2015 I'm upgrading several solutions with CLR projects using the old (now deprecated) "old syntax" to rather use the "new syntax" (i.e. switch /CLR instead of /oldSyntax).
The C# projects are targeting .Net 3.5 (we were hoping to migrate to a later version as a separate step).
I have completed all the syntax stuff (and have no further errors/warnings in that respect), but on building receive the following error:
"SomeAssembly.dll", or one of its dependencies, requires a later version of the .NET Framework than the one specified in the project.
The errors are resolved if I update the C# projects to target .Net 4.0.
Is .Net 4.0 a minimum requirement for using the 'new syntax' (/CLR switch)?
I haven't been able to find any reference material mentioning this.
EDIT: The C# projects are all library projects.
EDIT: Building under VS2008 the error doesn't manifest, but it does when building under VS2015.
I don't find any where that dot net 4.0 is prerequisites for CLR switch, Just check your web.config accordingly before updating the C# projects to target .Net 4.0.
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.
I've just installed C# Visual Express 2010.
The project is created under Console Application.
Any ideas? Thanks.
I'm trying to copy a range in excel and save it as a image file.
I have both PresentationCore and WindowsBase in my References.
But I'm still getting this error.
"Error 1 The type or namespace name 'Imaging' does not exist in the namespace 'System.Media' (are you missing an assembly reference?)"
Target Framwork is .NET Framework 3.5. It's still not working.
On versions of Visual Studio 2010, the default framework used for console applications is .NET Framework 4 Client Profile. The classes you're trying to use are probably not available for this version of the framework.
You need to change your project so it targets the full, .NET Framework 4 (or at least .NET Framework 3.5).
I don't have the express version installed to use as a reference but in regular versions of Visual Studio, you can do this by:
Right clicking on your project in the solution explorer and select Properties.
Under the Application tab, change the Target Framework from .NET Framework 4 Client Profile to .NET Framework 4.
Save.
You'll probably have to reopen your project so the changes could take effect. The assemblies should then be available to you.
I started a new winforms project, fairly simple, has a few labels, text boxes, and a button. All code is running fine. I forgot to change the framework version from 4 (using VS 2010) to 3.5 before I created the app and when I changed it to 3.5 or 3.5 client profile I get the following warning:
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".
It's not a huge amount of trouble to recreate this with a 3.5 setting from the start and I'm fairly sure I'm not using anything from the 4 framework that I need.
In most/all project templates in VS 2010 for .NET 4, the Microsoft.CSharp assembly reference is added. So when you created the project you were given this assembly reference automatically. You shouldn't have any problems just removing the reference.
I just wish to add my experience too. In my case, removing the Microsoft.CSharp reference was enough just to take the warnings away and compile the solution, however while using the console I got some errors still referring to the missing frameworks reference.
I then created an empty new console project; by default the ".NET FrameWork 4 Client Profile" was set, so I immediately replaced it with the ".NET Framework 3.5 Client Profile" option and saved. Then I copy&paste all my code from the original project and add all the references I used in the project. Then I renamed the solution, namespace, assembly name, etc, like my original project and compiled it. No warnings/errors and everything was OK.
I then tried to use the console application (on an environment with just the .NET 3.5) and everything worked flawless ^_^ (instead, just changing the .NET reference from 4 to 3.5 in the project proprieties, I got the errors I said above).
Hope this may help those having problems while just changing the "targeted framework" and removing the Microsoft.CSharp reference in an existing project.