I want to use an ASP.NET web application which was built using visual studio 2008 to 2013. will keep the .net framework to 3.5.
My concern is: There will be changes to .csproj and .sln after opening the project in 2013 but what about the dll to be deployed. would i need to update the hosting environment to 4.0 or any dependency upgrade?
The csproj and sln files will indeed be upgraded, but that has no bearing on the output of compilation.
As long as you continue to build for .NET 3.5, there shouldn't be any additional requirements to deploy your application. One thing to keep in mind is that VS2008 web deploy projects and database projects have been deprecated, and no upgrade path for those exists. So be careful if you're using either of those.
The safest approach for you will be to test the upgrade. Install VS2013, which runs side-by-side with VS2008. Open up the old solution, let VS update it, then do a test deployment. If there's a problem, just revert the change to whatever your last source controlled version is.
Related
I created a simple Web API project in Visual Studio 2015 using the .NET Core Framework. When I publish this project using the default settings, it creates the following:
In total there are 155 DLLs, 77 in the PublishOutput root and 78 in the refs folder.
Why put all the DLLs in the publish folder? Couldn't it just
reference the DLLs where they were installed from a single shared
location ?
Dotnet core tend to be very minimal as opposed to the previous versions of .net framework.
In dotnet core, the main purpose was making the core framework as small as possible and if you need more stuff, bring it in through NuGet packages.
So, many dependencies that used to be available in the framework are now moved to the NuGet packages and as you know there is a chain of dependencies in NuGet packages, so we will end up with so many libraries in our publish output, which is fine.
Another point being, most of the time, we're using project templates with too many dependencies that might not be needed whatsoever. So we can either start with a very minimal template and add needed stuff in it, or remove useless stuff from a more chuncky template.
I had a similar issue. When my local computer was upgraded from Net Core 2.0 to 2.1, my Core We Application which references a NetStandard application started publishing all DLL's in all referenced projects. I migrated my Core 2.0 application to 2.1 to match the highest version of SDK installed on my local and I could see my issue is now resolved. Publishing from the migrated(upgraded) application produced only the required DLL's. Hope this helps.
In previous versions of what is now .NET Core, using the dnx toolchain, it was possible to run an application straight from source code, without compiling to a DLL on disk. This capability was also present on Azure, allowing you to edit code on the server and have those changes reflected in the live site.
The new dotnet CLI run command seems to automatically create the familiar bin and obj folders with compiled DLLs in them, and the publish process from Visual Studio to Azure now no longer includes the C# source, just the DLL.
Is it no longer possible with the new CLI and other tools to run .NET Core code without creating a DLL on disk?
Short David Fowler response:
Dynamic compilation is gone in RC2. It only exists for views now. There are no plans to bring it back.
Why?
Architectural challenges and changes require to implement it on both .NET Framework and .NET Core. We did it with dnx and there were some problems (like some things being completely broken with in memory assemblies) that we chose to just avoid.
In this video, Scott Hanselman interviews a guy from the ASP.NET team. He says that one of the goals of ASP.NET 5, on top of .NET Core, is that the apps won't depend on the .NET Framework and GAC assemblies on the hosting server. Instead, .NET Core libraries will be released via NuGet packages and apps will be deployed with their dependencies.
One of the reasons for this is so Microsoft can quickly release a bug fix or new feature, and we don't have to wait until the new version (of the full framework) is installed on our hosting environment.
My question is:
Are the apps built on .NET Core really independent of the version of .NET installed on the target machine, and can they run even without the .NET Framework installed?
Yes, the framework you use in your application is completely independent of the .NET Framework installed on the target server, because the Core .NET Framework is referenced via NuGet packages and can be bundled up for deployment via the DNX Utility, specifically of interest to you will be the dnu publish command.
Here is an excerpt, describing what dnu publish does:
Publish (dnu publish)
The publish command will package your application into a self-contained directory that can be launched. It will create the following directory structure:
output/
output/packages
output/appName
output/commandName.cmd
The packages directory contains all the packages your application needs to run.
The appName directory will contain all of your applications code, if you have project references they will appear as their own directory with code at this level as well.
So the .NET Core will exist in the output/packages directory and will not need to be installed on the target server.
A normal .net core app requires that you install .net core on the machine you wish to run the application on. There is a way to avoid this however, by publishing a self contained app. You can publish your app with the requisite version of .net core included. This will make your app larger, but if you only need one application on a machine to run .net, you need a specific version of .net, or you want to make a portable application, this is a good choice.
So here's the thing. I recently updated a web project to use nuget for its dependencies, which in turn updated all of those dependencies to the latest versions.
Quite a task as there were some breaking changes, but I have the thing running locally perfectly.
We use TeamCity to pull the solution from bitbucket and deploy it the the local iis folder on a development (staging) server.
After a build, the website seems very poorly, first off it complains:
Could not load file or assembly
'file:///C:\web\Dev.Pegfect.Presentation\bin\mscorlib.dll' or one of
its dependencies. An attempt was made to load a program with an
incorrect format.
Which is strange since my local copy does not have a copy of mscorlib in its web bin folder. Should be using the GAC? If I remove the dll, I get a new error (some NHibernate issue complaining about reflection). I haven't pursued that since it all seems environmental.
If I copy my local bin folder over the server web bin, it starts to run ok albeit extremely slowly (relative to how it used to).
So, the question "what have you tried" - i am currently installing VS 2012 onto the server and will try building the project from source directly. I am also considering updating TeamCity from v7 to v9.
I could also try to reinstall IIS8.0 on the server.
These are desperate, blind shots in the dark. What would you try?
FWIW the project is targeting .NET 4.5.1 (ANY CPU)
OK, so I will leave it here as it might help someone.
So, the project has been building, deploying and running successfully on the server compiled to .NET 4.5.1 with no problem.
The recent packages update moved us from MVC v4 to MVC v5. (amongst other things). Running .NET fix tool suggested 4.5.1 was corrupted, so I downloaded the developer version and installed and now its fine.
I'm having problems with a website project and entityframework 5.
I'm going to put some background: The project type is Website, not web application or MVC, so when deploying, I simply copy all the files to the server and all is compiled when the first visit arrives. And that is what i think is causing the problem.
The project is targeting .Net 4.0 so when I install EntityFramework from nuget, the dll file version is 4.4. Running the project from VisualStudio with IIS Express is fine ( because VisualStudio knows that the target framework is 4 and compiles the project using .Net framework 4 dll ) but when copying the files to the production server where .Net framework 4.5 is installed, when first visit arrives, the website is compiled against the .Net framework 4.5 dlls and a problem appears because EntityFramework 4.4 contains definitions for classes ( like Column ) that are also contained inside the dataannotations dll from .Net 4.5.
The type 'System.ComponentModel.DataAnnotations.Schema.ForeignKeyAttribute' exists in both 'c:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.ComponentModel.DataAnnotations\v4.0_4.0.0.0__31bf3856ad364e35\System.ComponentModel.DataAnnotations.dll' and 'c:\Users\jyuste\AppData\Local\Temp\Temporary ASP.NET Files\portalempleado\4700d3ec\2c948b16\assembly\dl3\1c8b81c9\750c5018_1e5dce01\EntityFramework.DLL'
I suppose that upgrading the project to .Net 4.5 and updating the EntityFramework reference would solve the problem, but I can't do it right now.
Do you think that there is another solution?
From what you write, a possible solution would be to change the deployment procedure.
Instead of copying C# source files to a destination server, first publish the site locally to any directory. Publishing could be done with the "Build/Publish Web Site" option from the VS menu.
This will compile all your source files and create a deployment-ready sturcture containing only declarative code (*.aspx,*.ascx,*.asmx,etc) and the /bin folder containing *.dlls with compiled C# code.
Only then copy the published structure to the destiation server.