-
Notifications
You must be signed in to change notification settings - Fork 312
-
Notifications
You must be signed in to change notification settings - Fork 312
Publishing to IIS from VS #672
Comments
Yes, VS doesn't know about RC2. Try |
When using
|
Hey @moozzyk ... curious b/c I have PowerShell doing my publishing and haven't checked out your |
@guardrex - dotnet-publish-iis merely updates (or creates if needed) web.config file of a published application. It just takes the path to the folder the application was published to and goes to wwwroot opens web.config file and makes sure that httpPlatfomHandler (AspNetCoreModule) entries exists and sets the path to the executable. |
@moozzyk I see. I'm looking forward to checking it out. I was just wondering, because [EDIT] When I say "yet," I mean "yet to me" 😄 |
@guardrex - My understanding is that Debug vs. Release is basically the setting that is eventually being passed to the compiler (csc?). When you do |
Still doesn't work for me. (And I tired hard)
Running the command
|
@mikes-gh - I assume restore worked fine. if you try |
@moozzyk thanks for this I am using vnext feeds Installed dotnet cli from MSI on repo
dotnet restore ok.
|
Oh maybe coreclr x86 with dotnet cli x64 mismatch or arch Whats the consensus on architectures btw. Should I be sticking to x86 all round? |
if you are using dotnet you are not using dnx and therefore what dnvm list shows is irrelevant. |
Didnt realise that., The reason I ask is because this may be a path thing. When installing dotnet cli via administrator prompt, path variables are not appended to the current user but to adminnistator. |
@mikes-gh - I looked a bit into this today. The With dotnet you bring the runtime as the package. So, you select your runtime version just by setting it as a dependency in your project.json (dotnet is just a set of tools which are separate from the runtime). The dotnet build/run workflow is actually less magic then it was in dnx - in dnx the application was built at runtime. In dotnet things are more traditional - the application is built (can be done implicitly before you If you can run your application with |
We'll need to see if this is still an issue in 1.0.0 with the newer VS tooling. |
not working Product Information: Runtime Environment: dnvm list
cli-samples-master\HelloMvc>dotnet publish -o bin\pub
|
Side Note: DNX (the runtimes you listed with the The If you would like to temporarily try publishing the app without the tool, you can follow the steps below. In "tools": {
"dotnet-publish-iis": "1.0.0-*"
},
"scripts": {
"postpublish": "dotnet publish-iis --publish-folder %publish:OutputPath%"
} Confirm your <?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<aspNetCore forwardWindowsAuthToken="true" processPath="dotnet" arguments=".\HelloMvc.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" startupTimeLimit="3600" />
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
</system.webServer>
</configuration> You'll need to add a "content": [
"wwwroot",
"Views",
"logs",
"web.config"
], |
I can get dotnet publish to work OK now. dotnet ef and dotnet razor-tooling both run However if I try and use dotnet publish-iis I get
I am only building for net461 (no core targets) Is this because dotnet publish-iis is not cross compiling like the other tools. |
@mikes-gh You may be hitting https://github.com/dotnet/cli/issues/2071 |
publish-iis is in a Heisenber state right now. The old publish-iis (in the dotnet-publish-iis package) spits out the config for httpPlatformHandler and not for aspNetCoreModule. On top of that I don't think it accounted for the change where the web.config file was moved out of the wwwroot. The new publish-iis tool (from the Microsoft.AspNetCore.Server.IISIntegration.Tools) cannot work yet since the changes I made to cli to make the scenario where the package name is different from the dll inside the package) have not propagated to our build yet. At the moment I would recommend creating the web.config manually while I am working on sorting things out. |
Ok got it. Bit confusing having a new package different to tool name. Whats the resoning behind that. It might confuse new users. So to clarify dotnet-publish-iis package is being replaced by Microsoft.AspNetCore.Server.IISIntegration.Tools. Will that go in the tools section aswell.? |
It will look something like this in project.json:
There are pros and cons of each approach. We discussed it a lot and we settled on new names for each our tools (not only publish-iis). The work is being tracked here: https://github.com/aspnet/Coherence-Signed/issues/243 |
@moozzyk That link 404's. |
Looks like a private repo |
Yeah, forgot about this... |
So to clarify Microsoft.EntityFrameworkCore.Tools aswell? |
Yes, something along these lines. |
I am totally lost here.... Trying to get this thing running in AppService@Azure.. as far as i see i am missing a web.config or a mess.config :) somewhere... I installed on KUDU .net cli, compiled the app, dotnet publish, changed the web.config as above. I can start it manually (same as aspNetCore node), it works, and listens on 5000 However i am definitely missing something here... |
Closing this one, if you are still hitting this issue, please file another bug. |
Used to work.
I am using platform handler 1.2 on IIS 7.5
I am using rc2 vnext latest bits.
I am publishing via file share to iis using right click deploy.
This is the powershell script
When I publish I don't get any runtimes folder in approot.
Also my webconfig doesn't get copied as in my project
It is missing
Maybe its because of dotnet cli transition ?
The text was updated successfully, but these errors were encountered: