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.
Related
I have recently upgraded my project from asp.net core 1.1 to asp.net core 2.0. and app us using .Net framework 4.6.1. Application is working as expected on local dev machine but once it deployed to server with dotnet publish command I am seeing this error
InvalidOperationException: Cannot find reference assembly
'.NETFramework/v4.6.1/Microsoft.CSharp.dll' file for package
Microsoft.CSharp.Reference
I have also noticed that ref folder that use be present when using asp.net core 1.1 when published is now missing. How to fix this issue.
Same issue was resolved when MvcRazorCompileOnPublish was added to .csproj file.
Give it a try.
<MvcRazorCompileOnPublish>true</MvcRazorCompileOnPublish>
<MvcRazorExcludeRefAssembliesFromPublish>false</MvcRazorExcludeRefAssembliesFromPublish>
I noticed if you have the Views folder included with the compiled View.dll when you start your IIS pool, you get this error. I was doing this on purpose for a short term work around hack.
In my case (I run .Net core in console application mode) none of above solutions didn't works, i just downloaded .Net Framework 4.6.1 from this link.
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 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.
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.
I used the RC version of Visual Studio 2012 to create an ASP.NET Webforms project and I intentionally took the 4.0 version of .Net and of the project template to avoid complications after the release of VS2012.
Now I anyway bumped into the problem, that is revealed in the following error message:
'jquery' is not a valid script name. The name must end in '.js'.
As I noticed in the references, following assembly references are broken:
Microsoft.ScriptManager.jQuery
Microsoft.ScriptManager.jQuery.UI.Component
System.Web.Providers
I tried to re-install jQuery using NuGet but did not find these assemblies.
If I now create a new .Net 4.0 ASP.NET Webforms project in Visual Studio 2012 I get a lot of new references which are not present in my current (originally created in the RC-version, now opened in VS2012 RTM), like:
AspNet.ScriptManager.jQuery
AspNet.ScriptManager.jQuery.UI.Combined
but I can't find them among reference sources if I try to add a new reference to my original project.
How can I make my application runnable in VS2012?
Check packages
AspNet.ScriptManager.jQuery.1.7.1
AspNet.ScriptManager.jQuery.UI.Combined.1.8.20
make sure the following dlls are in the lib folder
AspNet.ScriptManager.jQuery.dll
AspNet.ScriptManager.jQuery.UI.Combined.dll
And check the reference in your project to make sure all references are resolved.
Sometimes, the dlls didn't added to the source control and when you do a get latest from the source control these two dlls are missing.