I am trying to find a way to run MVC6 application on IIS but without actually doing the publish. I am not sure if that is possible, and if not will it be possible in the future?
I would like to have similar behavior like on previous versions where I could easily debug my code and make changes while the application is running under IIS.
From your original question (emphasis added):
I am trying to find a way to run MVC6 application on IIS but without actually doing the publish.
From your comment to tugberk (emphasis added):
Right now every time when I make a change I need to call that dnu publish command in order to see my changes on IIS. I would like to see them only by doing rebuild.
Answer and reasons
You'll need to publish. There are at least two reasons:
IIS needs build output and
IIS needs a web.config file.
IIS might need a few other things too, about which I'm not aware. So, you'll need to publish. This isn't a big deal: after the onetime setup, publish doesn't take much longer than rebuild does.
Why do you need to publish?
In Visual Studio 2015, if you build an ASP.NET 5 web app, there will be no build output under your solution's directory, and IIS needs build output. By default Roslyn only runs code analysis without emitting build output.
You can change that default, so that Roslyn does emit build output, but that won't produce the web.config file that IIS needs. By going to View > Project Properties > Build and checking "Produce outputs on build", Roslyn will emit output to the artifacts directory. E.g:
artifacts/bin/MyWebApp/Debug/MyWebApp.1.0.0.nupkg
artifacts/bin/MyWebApp/Debug/MyWebApp.1.0.0.symbols.nupkg
artifacts/bin/MyWebApp/Debug/app/project.json
artifacts/bin/MyWebApp/Debug/dnx451/MyWebApp.dll
artifacts/bin/MyWebApp/Debug/dnx451/MyWebApp.pdb
artifacts/bin/MyWebApp/Debug/dnx451/MyWebApp.xml
artifacts/bin/MyWebApp/Debug/dnxcore50/MyWebApp.dll
artifacts/bin/MyWebApp/Debug/dnxcore50/MyWebApp.pdb
artifacts/bin/MyWebApp/Debug/dnxcore50/MyWebApp.xml
If you point IIS at the artifacts directory, you'll now have the problem of having neither a wwwroot nor a web.config.
So, you need to publish (or work out some other convoluted solution) for IIS to work with ASP.NET 5. There is a onetime setup if you want to publish from Visual Studio to a local IIS website. After the onetime setup, you can make changes to your code and publish in two clicks. Here's the onetime setup:
Right click the project.
Choose Publish.
Select File System and add a profile name (e.g. inetpub).
Change the target location to C:\inetpub\MyWebApp
In Settings, select appropriate settings. E.g.
Configuration: Debug
Target DNX Version: dnx-clr-win-x64.1.0.0-beta4
Click Publish.
Once publish completes, point IIS at C:\inetpub\MyWebApp\wwwroot and you will be able to browse to the web site. Further to the point, you can now change your code, publish in two clicks, and refresh your IIS site to see the changes.
Some gotchas
If you do choose to publish to inetpub, be sure to run Visual Studio as administrator, lest you receive an insufficient permissions error.
If you accept the default publish location (instead of using inetpub as shown above) watch out for path too long errors (i.e. > 260 characters.)
Final thoughts
Why not use Visual Studio and Debug > Start without debugging during development. With Roslyn and Visual Studio 2015, you can make changes to the code and see those changes by refreshing the web browser. No rebuild is necessary. It's a much nicer workflow.
It's possible. Under the root of your project (project.json directory), run the following command:
dnu publish --runtime active --out bin/artifacts
Once the publish is done, you have some stuff under bin/artifacts folder. Point IIS application pool to bin/artifacts/wwwroot folder we have just created and it should work. Keep in mind that you at least need .NET 4.5.1.
I'm assuming this is a development on IIS question. It's doable but it requires some work. The reason IIS doesn't work out of the box without a publish is because there is no user profile setup on app pools by default. The simplest thing you can do is to enable the user profile on the app pool, that will allow IIS to find the runtime in the user profile folder. On top of that, you require a web.config to specify which version of the runtime to use (dnu publish generates this for you so if you want, you can do a publish and copy the runtime folder). After doing that, pointing IIS to the wwwroot should just work (assuming you setup the right web.config with the right runtime and the right bitness).
You also need the correct AspNet.Loader.dll in the bin folder. If you use visual studio, it'll copy it in the right place.
Based on davidfowl answer i ran ASP.NET MVC6 on IIS without publishing application. But i still can't start debug it by F5(only by attaching to w3wp.exe).
Anyway i hope it would be helpful:
In the root of the project add "packages" directory(or name it whatever you like).
In global.json file add "packages": "packages". e.g.:
{
"projects": [
"src",
"test",
"wrap"
],
"sdk": {
"version": "1.0.0-beta4"
},
"packages": "packages" // <--
}
Packages will be now stored in this directory.
Create a "runtimes" directory in the root of your project.
Copy a runtimes from %userprofile%/.dnx/runtimes to /path/to/your/project/runtimes
Create a web.config in wwwroot of you project. e.g.:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="bootstrapper-version" value="1.0.0-beta4" />
<add key="dnx-version" value="1.0.0-beta4" />
<add key="dnx-clr" value="clr" />
<add key="dnx-app-base" value=".." />
<add key="runtime-path" value="../../../runtimes" />
</appSettings>
</configuration>
Create web application in IIS and point it to your project wwwroot.
My project directory structure:
Projects/
vNext/
packages/
runtimes/
dnx-clr-win-x64.1.0.0-beta4/
dnx-clr-win-x86.1.0.0-beta4/
...
src/
vNext/
wwwroot/ <-- IIS web application points here
web.config
...
project.json
...
global.json
vNext.sln
...
After this you will be able to attach to w3wp.exe and debug your application running under IIS.
Related
I want to create a web deployment package which leaves certain existing directories alone when deploying, e.g. a "logs" folder. Currently the package deletes/overwrites all existing files.
I can exclude the folder by adding extra parameters when executing the foo.deploy.cmd in the package, eg.:
.\foo.deploy.cmd /T """-skip:Directory=\\logs"""
This seem to work. But I can't figure out how to include this configuration in the package itself so it will be applied automatically.
I have a Asp.net Core website on .net framework 4.7. I use Visual studio 2019 with a pubxml publish profile.
I have tried adding MsDeploySkipRules to the pubxml but they don't seem to be passed to the package parameters. I am unsure if MsDeploySkipRules should work with "Web Deploy Package" or only with "Web Deploy"?
Edit: The problem may be related to I'm using Asp.net core. The MsDeploySkipRules seem to be applied in a regular asp.net (added in the generated deploy.cmd script) project but not if I insert the same in an asp.net core project file.
You could try to add the below code in your .csproj file to skip the folder at the time of publishing.
<ItemGroup>
<Content Remove="wwwroot\test\**" />
</ItemGroup>
also ste the delte existing file to true:
ASP.NET Core: Exclude or include files on publish
I have the following code:
var config = new ConfigurationBuilder();
config
.SetBasePath(Directory.GetCurrentDirectory())
.AddEnvironmentVariables()
.AddJsonFile("appsettings.json")
.AddJsonFile($"appsettings.{environment}.json", true);
Which works fine in development environment and production too. However if I place this:
Raise<FileNotFoundException>.If(File.Exists(Path.Combine(Directory.GetCurrentDirectory(), "appsettings.json")),
$"Could not find the settings file");
It raises exception during debug sessions and release sessions (basically when the app is not published and executed from Visual Studio) that file could not be found which is kind of correct because VS2017 does not copy settings file to the debug folder and instead keep them in the source folder. So my question is,
how does the dotnet core resolves the configuration path for aspnet core?
I think you're getting confused on things here. The configuration is pulled by default from the entry point directory. Inside Visual Studio or when running dotnet run from the command-line within your project root, everything works fine. Also, when you publish, the published directory will contain the configuration files alongside the entrypoint DLL, so this will work fine as well.
What you seem to be talking about is running from the bin directory, which is not a supported thing. The bin directory is effectively a cache. It's not a published version of your application, and thus cannot be run as if it is.
I just upgraded my .net core 2.0 project to 2.2. To my knowledge, I didn't change any other settings, but now when I publish to my file system, it publishes a ton of folders and dlls that it didn't before.
Do I need to publish them? If not, can I suppress their output?
Here is my publish profile settings:
Here is what the output directory looked like before the upgrade:
Now, here is just a snippet of what the output directory looks like:
Introduction: This issue seems to result from .net core 2.0.
From the picture you shared above. I know you choose Framework-Dependent Mode.
In this mode, generated files should be like what you have in picture1. And if your choose self-contained mode, generated files should be like what you have in picture2.
But in .net core2.0, there seems to be some different. When we publishing projects in .net core2.0, or just upgraded from 2.0 like yours. We must set self-contained property to false explicitly so that the Framework-Dependent mode can work normally.
Do I need to publish them?
No, you don’t need to publish generated files from self-contained mode as you choose framework-dependent mode.
If not, can I suppress their output?
Here is one workaround:
Looks like you use VS IDE to publish it, when publishing make sure choose 'create profile'. So we will have a PublishProfile, we can find it below Properties in Solution Window. Open the FolderProfile.pubxml and add the <PublishWithAspNetCoreTargetManifest>true</PublishWithAspNetCoreTargetManifest> in the PropertyGroup. Also, we can set the <DeleteExistingFiles>false</DeleteExistingFiles> to true.
After that, publish the project again the issue can be resolved.
The final format of PublishProfiles looks like below:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
...
<publishUrl>bin\Release\netcoreapp2.2\publish\</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<PublishWithAspNetCoreTargetManifest>true</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
</Project>
In addition: You can find more info from this issue. Thanks to natemcmaster. His advice do work at my side.
Overview
I am building a deployable web package that can be imported into IIS that automatically prompts for settings needed by my ASP.NET Core application. I already created a package that will deploy just fine, except after deploying, I need to manually find/edit my appsettings.json file.
I know this package can include a parameters.xml file that will automatically prompt and fill in my appsettings.json when importing an app into IIS. I have already made a parameters.xml file, and manually added it to my package after building it; it worked as expected. I'd just like to have msbuild automatically add the parameters.xml file to the package for me.
A separate project of mine (ASP.NET MVC 4) already does this. For that, I simply needed to put my parameters.xml in the same folder as my .csproj. I tried doing the same here, but had no luck.
Repro Steps
I created an ASP.NET Core Web Application
Using .NET Framework on ASP.NET Core 1.1
I then went to publish my website
Selected 'Folder' (just to get a template)
I then edited the profile and changed the WebPublishMethod to Package and added the three lines below it.
<DesktopBuildPackageLocation>bin\$(Configuration)\$(MSBuildProjectName).zip</DesktopBuildPackageLocation>
<PackageAsSingleFile>true</PackageAsSingleFile>
<DeployIisAppPath>External</DeployIisAppPath>
I then published one more time. Now I get a WebDeploy package that I can deploy to IIS.
Great! but...
I'd like to customize the parameters.xml.
For previous projects, I was able to add a parameters.xml file to my project root, and VS/msbuild would automatically add it to my published package. This currently works for a different project using ASP.NET MVC 4.
So, I tried the same thing for this project. First I added a settings.json with a very simple setting:
{
"SettingName": ""
}
Then I added a parameters.xml file that I know works to my project root. (If I manually replace the parameters.xml file in Sample.zip package, it correctly prompts and replaces my setting when deploying)
<parameters>
<parameter name="IIS Web Application Name" value="External" tags="IisApp">
<parameterEntry kind="ProviderPath" scope="IisApp" match="^c:\\users\\joshs\\documents\\visual\ studio\ 2017\\Projects\\Sample\\Sample\\obj\\Release\\net461\\win7-x86\\PubTmp\\Out\\$" />
</parameter>
<parameter name="Setting Name" description="Enter a custom app setting" defaultValue="Default Setting Value">
<parameterEntry kind="TextFile" scope="obj\\Debug\\net461\\win7-x86\\PubTmp\\Out\\appsettings\.json$" match="(?<=\"SettingName\"\s*:\s*\")[^\"]*" />
</parameter>
</parameters>
Again, I right click and Publish once more. This time with the parameters.xml file.
I expect the Sample.zip to contain the parameters.xml that I added to my project root, but it does not. It is the exact same as from my original publish.
Question
During the build process when creating a web deploy package, how do you include custom settings in the parameters.xml?
I have already tried this...
I already looked at https://stackoverflow.com/a/46338042/2494785, but with no luck, though my command differed slightly from the original poster.
PS C:\Users\joshs\Documents\Visual Studio 2017\Projects\Sample> & 'C:\Program Files (x86)\Microsoft Visual Studio\2017\E
nterprise\MSBuild\15.0\Bin\MSBuild.exe' .\Sample.sln /t:Sample /p:DeployOnBuild=true /p:PublishProfile=FolderProfile /p:
ProjectParametersXMLFile="C:\Temp\parameters.xml"
I was able to solve this from peteawood's comment from an issue posted on GitHub.
https://github.com/aspnet/websdk/issues/201#issuecomment-349990389
In ASP.NET Core 2.0+ you can add the following to your .csproj
<Project Sdk="Microsoft.NET.Sdk.Web">
.
.
<Target Name="AddMoreParameters" AfterTargets="_CreateParameterFiles">
<Copy SourceFiles="Parameters.xml" DestinationFiles="$(_MSDeployParametersFilePath)" />
</Target>
</Project>
SourceFiles should point to the location of your parameters.xml file from the perspective of the .csproj file. My parameters.xml is found in the same directory as my project file.
I believe I can just pass parameters via cmd-line as properties for msbuild.
It's not fully what you asked for I understand.
For example, in the following command I'm passing DeployIisAppPath property:
dotnet publish /p:WebPublishMethod=Package /p:DeployIisAppPath=mysite/myapp /p:PublishProfile=rnddev03-core-dev
and in the output folder we'll get xxx.SetParameters.xml file with:
<parameters>
<setParameter name="IIS Web Application Name" value="mysite/myapp" />
</parameters>
I have a Visual Studio 2010 solution that is set to build in Debug x86. Visual Studio therefore sets the output path to \bin\x86\Debug, which seems logical enough.
The solution contains about 50 projects; the start-up project is a WCF project.
When I do a build, I would expect all output dlls to go to \bin\x86\Debug, as that is what is set in the project settings. But weirdly, I see dlls being created in bin\x86\Debug and in \bin. Why would Visual Studio put any dll in \bin if the output path is not set to that directory? It seems that all dlls go to \bin\x86\Debug, and all dlls except for the start-up project go into \bin. Any idea why it would do that? (We have other solutions that don't use WCF, and they don't have this problem.)
The other annoyance is if I run the service from Visual Studio and then try to access my service in a web browser, by going to http://localhost:1240/MyService.svc, it doesn't work, because the start-up project dll is missing from /bin. I therefore have to manually copy this one dll from \bin\x86\Debug to \bin, so that all dlls are found and the service runs normally. (We could of course add a custom post-build step that does the copy, but you'd think there'd be a better way!)
To those of you working on WCF projects, do you leave the output path at \bin\x86\Debug? (Perhaps there is a way to configure the service, eg in the web.config or .svc file, so that it knows the binaries are in \bin\x86\Debug instead of \bin?) Or do you change the output path to \bin so that you can run your service straight from Visual Studio?
If you open the property page of you WCF Hosting project and goto tab Build, under the Output section of this tag there is a textbox that contains the location of the output binaries.
For a WCF project the binaries should go to bin directory irrespective of the build type (suc as Debug, Release). Make sure this value has been configured correctly.
The value needs to be configured for each build type\configuration.
If you need, for whatever reason, different outputs from different build configurations in different folders you could specify them like you did first and use a post build event command line that copies from your specified output folder to bin.
Like:
- untested code -
COPY/Y "$(OutDir)\*.*" "$(SolutionDir)$(ProjectName)\bin\"
- untested code -