I have already included the settings mentioned in post
How do I target an already existing application pool with webdeploy?
still when i deploy the WCFService it gets the default application pool of the sites and not the one mentioned in parameter.xml file.
MsDeploy command that i am using
Related
I am working on a .NET project that I publish on Microsoft Azure.
When I publish the app, I see some termination in log files. In particular, the first one is:
Application 'D:\home\site\wwwroot\' was recycled after detecting app_offline.htm.
I have no app_offline.htm in my directory in Visual Studio.
So I am publishing the application, and it immediately terminates, hence stops working.
How do I fix this?
Please check your .csproj in Visual Studio, because it probably holds the setting you're looking for. One of the properties you can set for Web Deploy (MSDeploy) is EnableMSDeployAppOffline, which seems to default to true.
This is causing the app_offline.htm file to be created. Set the EnableMsDeployAppOffline value to false if you don't want to take the app offline when publishing.
Also, taken from Visual Studio publish profiles (.pubxml) for ASP.NET Core app deployment - Compute project items.
When an ASP.NET Core project references Microsoft.NET.Sdk.Web in the project file, an app_offline.htm file is placed at the root of the web app directory. When the file is present, the ASP.NET Core Module gracefully shuts down the app and serves the app_offline.htm file during the deployment.
I have an ASP.NET Core web site that I'm deploying to a VM running IIS on Windows Server 2019. (It's on Azure, but I don't think that that really matters here.) There are some settings that I've configured as environment variables in the IIS Manager. It works fine, but when I deploy a new version using Web Deploy from Visual Studio, the settings get wiped out and the site breaks until I go back into IIS Manager and set them again. Is there a way to set IIS environment variables on the server so that the won't get erased when I deploy a new version? I'd prefer not to use appsettings.json because I don't want the values checked into my Git repository.
can someone explain whats the difference between these settings?
The reason im asking: default pick was IIS Express and multiple processes used my logger and created duplicates in the log. But when i picked Project, there were no duplicates in the log.
The first is IIS Express that will use IIS Express to host this project and the second is Project that will run this project and debugging it.
If your project include Main that you can select Project to Launch and VisualStudio will debugging it.
The last one is Executable that will use the other application to run this project like dotnet run xx.dll and you should set the running application path when you select Executable and set some arguments. The VisualStudio will debugging the running application like use attached process.
See:Working with Environments and Launch Settings in ASP.NET Core
Use multiple environments in ASP.NET Core
My application can not deploy because of the following error:
Web deployment task failed. (The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v2.0'. This application requires 'v4.0'.)
Right now, I'm attempting to deploy my .NET application to IIS. VS is attempting to target the "DefaultAppPool" application pool. I want it to instead target the "ASP .NET v4.0" application pool. How do I do that in Visual Studio?
I am trying to not change any settings within IIS if possible.
I don't know if this would be considered a hack, but it got the job done without any issues.
What I did was I first created a folder in IIS and then converted it to an application. After which, I had it target the .NET 4.0 application pool and voila, Visual Studio was able to deploy the application without the error.
I hope this helps people in the future that Google their issue and come upon my question.
When trying to deploy an ASP.NET application deployment package to IIS, I receive an error
(The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v2.0'. This application requires 'v4.0'.
I have taken these steps:
ensured my server's default .NET Framework version is 4 (restarted the IIS service on the machine)
ensured my web application is set for .NET 4
ensured the application's web.config has no references to requiring .NET 2 or 3.5
What is the root cause of this error, and how can it be solved?
Web Deploy uses the default IIS web site settings while publishing. To change/confirm this on your IIS machine:
go to IIS->Default Web Site->Basic Settings->Application Pool
select ASP.NET v4.0 or the appropriate app pool using the appropriate Framework version
If you're trying to import this application into an existing site, ensure that its application pool is the same version. I was attempting the same, but didn't realize my 'new' website was running on an app pool that was v2.
Be sure that your Application Pools by default are configured also for v4.0 by default.
ASP.NET 4 is installed when you install Visual Studio. However, the installation process does not automatically register ASP.NET 4 with IIS, and existing IIS Web sites are not automatically assigned to.NET 4 application pools.
To fix this, register ASP.NET with IIS and set the application pool of the destination IIS Web site to the .NET Framework version that is required by the package.
To do this, open Command Prompt as administrator and go to C:\Windows\Microsoft.NET\Framework64\v4.0.30319 and type: aspnet_regiis -i
According to Web Deployment FAQ for Visual Studio and ASP.NET
I was trying to use Continuos Deployment in VSTS/TFS, in my Release Definition (which was default), I had a IIS Web App Manage Task (named Manage IISWebApplication), where it had Parent website name setting with the correct website name, and the Virtual Path setting was right as well.
I just had to fix the web site name in the Deployment Process section, where it has the Environment Name and Website name as well.
Silly, but it got me 2 days to notice the web site name was in two places in the Release Definition.