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.
Related
So what I'm trying to do is build a .NET Core app with MSBuild, and have it create the web deploy folder but without automatically putting it in a zip file. I can do this for .NET Framework apps by using /p:WebPublishMethod=Package and /p:PackageAsSingleFile=false, it creates the same folder structure but without adding it to a zip file. However with a .NET Core app, it seems to ignore this flag and always zips up the final package.
The reason I do not want it zipped up is I need to add a number of "custom" files to the build before I can deploy it. I can't add the files during the build itself because we have a number of different clients, and they all share the same "base" software, and then the client specific files need to be added afterwords. So I want to build the "base" software, then be able to copy the output folder, add the client specific files, and then zip up that build to be deployed to IIS. This saves a tremendous amount of time because the alternative is doing a new build for each client, even though 95% of the software is the same.
So is there a different way to accomplish this with .NET Core apps?
I've been testing with MSBuild via command line. The solution has a mix of .NET Framework and .NET Core asp.net websites. This is what i'm running:
msbuild.exe "Solution.sln" /nologo /nr:false /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=false /p:SkipInvalidConfigurations=true /p:PreBuildEvent="" /p:PostBuildEvent="" /p:BasePackageLocation="C:\Temp\BuildOutput" /p:platform="any cpu" /p:configuration="release"
This works for the .NET Framework websites, but the .NET Core websites continue to be zipped up
And just a note that the BasePackageLocation is a custom property that sets the PackageLocation to "$(BasePackageLocation)\$(MSBuildProjectName)\" so that each website is put in its own sub-directory
So is there a different way to accomplish this with .NET Core apps?
Sorry but the answer could be negative. This is one issue about publishing .net core projects, it has been reported to Product Team, there might be a long way to go before the fix.
For web deploy package mode in .net core, you'll get WebApplication.deploy.cmd in the same folder where the .zip exists, many commands in the xx.cmd are associated with the xx.zip, so it's not recommended to manually do something to unzip it.
I suggest we can track the issue there(DC) and I will update the answer if there's any update or fix :)
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 have an ASP.NET Web API project created on Windows using Visual Studio. How can I set this up for use with DNX/DNVM (on a Mac)?
Switching to Git solved the source control compatibility with TFS. But I wasn't able to find references to getting a project working across both these development environments.
I'm assuming as a first step the project will have to be migrated to ASP.NET 5/vNext but wondering other problems lurk around the corner with different project members using different environments.
I get an error when I run - git:(master):dnx . kestrel
As you mentioned yes you will have to migrate any namespace changes. I have a project that is developed across both. Also changing csproj files to xproj. Support is coming for some kind of interop between the different project types but its not here yet.
For build, publish, deploy from git without relying on VS publish capabilities or MSBuild you can follow my blog post here.
Basically you use DNU to publish and then kudu to deploy.
If I understand correctly with our deployments most code gets compiled on the workstation, and the aspx/ascx files get compiled on first access on the server. Is there anyway to precompile these?
I would like to do this to trigger compile errors at workstation compile time, rather than at "run-time" and also to potentially allow C# 4 features to work in views as we use .NET 3.5 on the servers.
Visual Studio provides the command-line tools aspnet_compiler and aspnet_merge, and I blogged about how to call them from a batch file.
You can also add aspnet_compiler as a Post-Build event in the project to find compilation errors, but it slows down build times.
If you develop for .Net 4, you need to have the .Net 4 framework installed on the web server.
Follow this link for precompilation overview: ASP.NET Precompilation Overview
Also, if on server 4th framework doesn't installed you can't use C#4 features in your project even if you will precompile application on your dev machine.