i am working on a dotnet C# web application which was initially created with VS 2003. My goal is to upgrade this application to Dotnet 4.0 without changing any functionaltiy. The solution has 9 projects (1 web + 8 Library projects). The Web project refers the 8 libraries in DLLs. To start off, I created a New project in VS2010 and added the all the Project files from the existing source code. Every time i add a project file to my solution, i was prompted with the Converison wizard and i completed the conversion wizard succesfully and now the solution works fine. After the conversion, i noticed that Except the "Web" project, other projects are converted to Dotnet 2.0 but not 4.0. My application runs without error if i run it locally using VS2010. My questions are
Why the Class libaray project did not upgrade to 4.0? Currently the
Web project is shows up as Dotnet 4.0 and Libaray projects shows up
as Dotnet 2.0.
Can i deploy the application to IIS 7.0 with the
Dotnet runtime of 4.0? Will the Dlls created in version 2.0 work if my application
uses Dotnet 4.0 runtime version?
Please help...
If your'e migrating now, why not move directly to Visual Studio 2012, instead of 2010?
Anyway, what you can do is open the project properties in each of your projects, and change the target framework to the .NET framework 4.0.
Then if you get any compilation error you can probably easily solve it individually. This should be relatively easy if your projects are not too big.
As for your specific questions:
The automatic conversion would only change the format of the solution/projects to be compatible with the new version Visual Studio. It shouldn't change the target framework but you can change that yourself.
Yes, assemblies targeting .NET 2.0 can be loaded and used from assemblies targeting .NET 4.0.
1) Upgrading the solution/projects file only upgrades it's format so you can open it in VS 2010. It will usually leave the targeted .NET setting at the previous value. These are two seperate things. The wonderful thing about VS 2010 is it let's you target whatever version of .NET you desire, so no longer do you need multiple version of VS installed to support differnt .NET versions. It didn't change the targetted .NET version because it leaves it up to you. You can change it under the project settings and recompile your library projects to regenerate the DLLs
2) You will need an application pool for .NET 4. .NET is backwards compatible in that a .NET 2.0 app can run on a machine with .net 4 installed. However, the application pool for 2.0 applications must be separate from 4.0 apps. So it's just a matter of putting the app under the right app pool.
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".
I'm working on upgrading a windows application/service to target newer .NET frameworks for a client. This is the first time I've done anything of the sort. I changed the Target Framework in the C# project's properties window to 4.5, rebuilt the project without any errors, and then tried to run setup.exe. When I run this, it says:
This setup requires the .NET Framework version 2.0.50727.
Does anyone know why this would be happening? I read about launch conditions and that it could possibly be checking that the client computer requires v2.0, but I don't see an option to view the launch conditions in Visual Studio 2013.
Thanks
I make a c# application project. this project run on my computer good, but in other computer says you must first install .NET Framework 4.0 to run this application.
How to embed .net framework 4.0 into c# project.
Thanks
You can't embed the framework into your application sine it needs to be installed on the client machine (not just xcopy'd like your app).
You'll need to create an installer which will take care of detecting and installing the required framework version before installing your application.
There is a tutorial here which shows how to create a setup project.
Once everything is set up, go to Project > [project name] Properties, click the Prerequisites... button and check .Net Framework 4. By default, the setup will download the Framework from Microsoft, so it will need an internet connection.
Does anybody know how I can run Awesomium.NET on .NET 3.5? Seems to only work on 4.0-4.5.1 right now.
According to this question, Awesomium 1.7 should be compatible with 3.5 by adding Awesomium.Mono to the project instead, but it seems like I'm not able to do that. When choosing 3.5 project in Visual Studio the Awesomium.Mono just disappears from the references list.
Well when I started using Awesomium web browser at version 1.7.0 the reference dll are builded using .net 4.0 version. You should try to look for an older version like 1.6.6 or 1.6.5 and check if they are builded using a older .net version. If you target your project to .net 4.0 you should not have any problem because at least windows XP with service pack 3 should have installed .net framework 4.0. But windows XP support has ended.
A quick solution (but not the best) is to target the project to the .net 4.0 and export all dll references to the build path. That should make no problems when deploying the app to your clients machine because the exe will reference to the build path.
Could you give me the reasons of why you are targeting .net 3.5 so I can understand a little more your issue with .net versions and try to think about another solution for you?
When I try to do it I get the error "The application requires .NET Framework 3.5 SP1." I have .NET 4.0, how do I install 3.5 SP1? Can I have both?
Feel free to install all versions of .Net. They will not interfere with each other!
For adding dependencies to your project I recommend NuGet. Really handy and makes the project clean by adding references into it instead of requiring additional installation packages.
.Net 4.0 projects are capable of using .Net 2.0, .Net 3.0 and .Net 3.5 libraries. But note that projects running under ".Net 4.0 Client Profile" can have problems doing this, and you only get a misleading error when attempting to run the project. From within Visual Studio everything seems right.
Just like Tedd Hansen says you can sure have as many .NET versions as you want in your computer for it creates no conflict at all. I take it you are just trying to install something. If that's the case then you can always use this link to download the bootstrapper that will determine the right 3.5 verison for you (x86 or x64) and download and install it.
If you are developing an application you can change the target framework of the project by going to the project properties page and, in the compile tab, click on the "Advanced Compile Options" button. There you'll be able to choose.
And, also as Tedd mentions, you should avoid targeting the "Client Profile" versions unless you specifically know that the subsets present therein are sufficient.
On my machine (Windows 7 Enterprise x86) I have installed .Net framework 4.0 and Enterprsie Library 5.0 without any problems. Maybe some other issue you're facing?
IAdapter,
I've answered this already. See my answer and the workaround in the comment dtd Feb 5, 2011.