AzureRm Web App Deployment Task failed

[zechariahks]

Is this task released officially? I am seeing this task in couple of our VSO instances. Tried using this task to deploy to one of our web app. It failed with below error. Can some one correct me if I am passing the values correctly? or let me know if this task is not ready for consumption yet.

Running msdeploy command:

2016-05-05T23:10:10.4737277Z "E:\agent\tasks\AzureRMWebAppDeployment\1.0.2\MSDeploy3.6\msdeploy.exe" -verb:sync -source:package="E:\agent2_work\5d7d8da1d\EC.NGVL.Payments.PaymentVoidService\Packages\PaymentVoidService.zip" -dest:auto,ComputerName="https://PaymentsVoidService-envd-production.scm.azurewebsites.net/msdeploy.axd?site=PaymentsVoidService-envd(production)",UserName="$paymentsvoidservice-envd",Password=****,AuthType="Basic" -setParam:name="IIS Web Application Name",value="PaymentsVoidService-envd(production)" -enableRule:AppOffline

2016-05-05T23:10:11.3537272Z ##[error]System.Management.Automation.RuntimeException: Error: Source does not support parameter called 'IIS Web Application Name'. Must be one of ().

[chshrikh]

This is a preview task.
Deployment team is taking a look into this error

[Ajay-MS]

@zechariahks - Does you webapp package file contains a parameters.xml file? If It contains, this file should have a parameter "IIS Web Application Name" . If not you can export zip from VS which automatically create parameters.xml with "IIS Web Application Name"

[zechariahks]

Hi,

I am not using the actual package file which gets generated during the build. I am updating few config files during release and packaging that folder to .zip. I can see the parameters.xml file in the package file generated by build, but not in the custom zip file which I am generating during release. Is there any way that I can skip this or is it mandatory to use the package file generated by build?

[zechariahks]

correction, Is it mandatory to have parameters.xml file inside .zip?

[Ajay-MS]

@zechariahks - Yes , for AzureRMWebApp task it is mandatory to have parameters.xml and also parameter.xml should have parameter "IIS Web Application Name" . It is recommended to use generated build but if you are packaging yourself you can follow following link for configuring parameters for package deployment - Configure Parameters .

Another way is use zip generated by build and uncompress this zip. Update config files and then re-zip uncompressed package again in this way you will not loose parameters.xml

[zechariahks]

@Ajay-MS - Thanks you for the information. I have tried copying the parameters.xml file to package folder and zipped it. It worked fine.

[robdmoore]

I'm trying to use this with an ASP.NET Core RC2 project and (from what I can tell at least) it's not easy to create a Web Deploy package anymore.

I've created a normal zip file of the result of dotnet publish, but it won't work with this task without also including the parameters file. To me it's an unnecessary and confusing thing from a user's perspective to need that, but I can see why you need it looking at the msdeploy.exe call you make though ;).

It may well be a non-issue soon when ASP.NET Core uses MSBuild again since I'm assuming creating a Web Deploy package will be a first class citizen again?

#foodforthought

[gencebay]

you can follow these steps;

workingDirectory

project.json
web.config
parameters.xml
Views (sample.cshtml, ..)

dotnet restore & dotnet publish -c Release -f net46 -o bin\<projectName>\
msdeploy -verb:sync -source:contentPath=%cd%\bin\<projectName>\ -dest:package=C:\temp\<projectName>.zip -declareparamfile:parameters.xml

so you can use this package to deploy anywhere and also check this: IIS Web App Deployment issue

[bragma]

I have the same problem here. I have an asp net core (RC2 and using new461 but it's just a detail) with 2 webjobs. I'd like to deploy from VSTS but the process is confusing for me.
At the moment, I have may Web App in the "\home\site\approot" folder, while the webjobs are of course in "\home\site\wwwroot\App_Data\jobs\continuous".
I'm not sure how to create my artifact zip for this and also how to generate the parameters.xml

[bragma]

@gencebay how can I generate the parameters.xml for an Asp Net Core Project?
Thanks!

[gencebay]

You can create it manually like that and save as parameters.xml

<parameters> <parameter name="IIS Web Application Name" defaultValue="MyApp" tags="IisApp" /> </parameters>

and make sure -declareparamfile:parameters.xml arguments path is correct for msdeploy.exe

[bragma]

@gencebay thanks a lot! Is there any doc helping me what to set an the correct values for deploying on Auzre Web App? (as an example I am not sure what to set as application name)

[Kizmar]

Getting this same "Error: Source does not support parameter called 'IIS Web Application Name'. Must be one of (). Error count: 1." issue. None of this fixed the issue for me. I'm using a "Deploy AzureRM Web App" task to package a .Net Core 1 app. I tried manually adding a "parameters.xml" file to the solution and adding it to project.json "includeFiles" so it's in the zip file. I also added "-declareParamFile:parameters.xml" to the "Addition Arguments" field in the task. No luck.

[Edit] I also tried this with no luck: http://www.factus.dk/post/2016/07/04/Build-and-deployment-of-ASPNET-Core-10-to-Azure-App-Service

[sandorfr]

Is this definitely weird to make this mandatory, it was not in Azure classic.
In our case (and judging by people commenting here, we are not the only ones) our configuration does not come from source control nor from artifacts downloadable by everyone involved in development. This should be optional.

[kmkumaran]

We are relaxing this requirement and make parameters.xml optional. We will update you soon once we have the fix in place.

[sandorfr]

Greet news @kmkumaran this will help with #2122

[pherbel]

@kmkumaran Could you please provide an ETA?

[kmkumaran]

Our plan is to get this fix as part of next VSTS sprintly deployment (~3 weeks from now).

[pherbel]

I see. Thanks

[erikest]

Until that fix comes along: I've had success with putting a parameters.xml file, as @gencebay suggested, into the repo and then specifying the SetParameters option of the Web App Deployment build step to use this file.

[bragma]

@erikest have you deployed on azure? Can you share your parameters.xml file?
Thanks!

[erikest]

It looked just like this, but with "MyApp" being replaced of course:

[erikest]

oops:
<parameters> <parameter name="IIS Web Application Name" defaultValue="MyApp" tags="IisApp" /> </parameters>

[bragma]

@erikest thanks. Pardon my ignorance (this may be a stupid question), how is the application name related to Azure's App Services name? I.e. Where did you get "MyApp" for deploying on an existing Azure Web App?

[bragma]

Hi,
thank you all for the help. At the end I managed to make it work. To make things simple, I've just added a CMD step to my VSTS build definition to create a "production.xml" file in the artifacts folder (using echo):

Tool:
echo

Arguments:
^<parameters^>^<parameter name="IIS Web Application Name" defaultValue="appname" tags="IisApp" ^/^>^<^/parameters^> > $(Build.ArtifactStagingDirectory)\production.xml

Regarding the name to use, I took it for the "FTP/Deployment username" setting in Azure's portal (which is also used in a dozen of other places to refer to the app - maybe it was obvious, but I wasn't sure).

[frourke]

@kmkumaran did the sprint get deployed with this fix? I am still getting this error.
2016-09-09T01:33:10.1595729Z ##[error]Error: Source does not support parameter called 'IIS Web Application Name'. Must be one of (). Error count: 1.

[KungRaseri]

I'm getting the same issue "Error: Source does not support parameter called 'IIS Web Application Name'. Must be one of ()."

I am using the WinRM task in VSTS (cloud).

[sandorfr]

Looks like this issue shouldn't be closed, It's obviously not done. @kmkumaran any news?

[mvvsubbu]

We have enabled support for deploying a non MsDeploy zip, where the parameters.xml is not required. However when the MsDeploy zip is provided 'IIS Web Application Name' parameter is required, I am re-opening the issue to track the same.

Once we address the 'IIS Web Application Name' parameter issue for MsDeploy zip we will update you.

[haydenhancock]

Any ETA on release? I am experiencing the same thing as mentioned above but for on-premise.

[RoopeshNair]

@haydenhancock  quick question, how are you generating the package?

We detect that the package has been generated using msdeploy, if it has a paramters.xml file. And the parameters.xml should have the "IIS Web Application Name' parameter.
If you have used any other mechanism to generate the package, in absence of parameters.xml, it will be considered as non-msdeploy and it should work as well.

[haydenhancock]

@RoopeshNair Actually, I am using the dotnet CLI which doesn't seem to package the bits in the same way that MSDeploy does. I am able to use other means to release the bits to specific environments.

[vincent1173]

@haydenhancock , If package is generated from dotnet CLI, then parameter.xml won't be present in package. We will be able to deploy that package using this task.

@sandorfr @furyanPDX @frourke

If you have generated package using msbuild task or visual studio which is usual scenario, you should have the parameters.xml generated with "IIS Web Application Name". Can you share the command you used to generate the package which had parameters.xml file but not "IIS Web Application Name" paramter.

Recommended methods to generate package:

Visual Studio: https://codemonkeygotsmarts.wordpress.com/2014/04/21/msdeploy-create-a-web-deployment-package-from-visual-studio/
Team Build: Using ASP.NET (Preview) template

[taspeotis]

Hi, I've had my own troubles with this task and I've been keeping an eye on this GitHub issue as a reference. Thanks to everyone who's come before me and tried to make it work. Sorry if I repeat something in the thread above.

If package is generated from dotnet CLI, then parameter.xml won't be present in package. We will be able to deploy that package using this task.

This isn't necessarily true and I think a lot of the problems here are presuming that Parameters.xml means a non-.NET Core package. I have a Parameters.xml file included because I use Parameters.xml to parameterise my deployments (surprise). Instead of targeting web.config, it targets appsettings.xml.

(See AddXmlFile.)

So presuming Parameters.xml means the application is not .NET Core is wrong.

Can you share the command you used to generate the package which had parameters.xml file but not "IIS Web Application Name" paramter.

At least for .NET Core, you can achieve this by using dotnet publish and the following in project.json:

"publishOptions": {
  "include": [
    "wwwroot",
    "Views",
    "Areas/**/Views",
    "appsettings.xml",
    "Parameters.xml",
    "web.config"
  ]
}

Because Parameters.xml is generated by hand (by me) I omit the IIS Web Application Name (and others).

Really this task needs some way to determine -dest:auto... vs. -dest:contentPath... that isn't based on Parameters.xml. At a pinch it could use the contents of Parameters.xml (if there's an IIS Web Application Name parameter or not). Given just how much back-and-forth there has been, a select list in the task of...

-dest Provider:

• Automatic Detection (Parameters.xml) Default
• auto
• contentPath

(i.e. no magic guessing)

...would go a long way to giving me the flexibility to use this task instead of a command line task. For what it's worth, here's the command line I'm using:

-verb:sync -source:package="MyPackage.zip" -dest:contentPath="MyPackageSiteName",computerName="https://$(winrm.machineName):8172/msdeploy.axd",userName="$(winrm.userName)",password="$(winrm.password)",authType="Basic"

Plus -setParam... as necessary.

[vincent1173]

@taspeotis , this issue was already fixed and will be available in the upcoming on-prem release.

[taspeotis]

Thanks for the quick response.

The code you linked me to still exhibits the problem I'm describing. I have a package that needs to be deployed with -dest:contentPath and it has a Parameters.xml file.

        if(isParamFilePresentInPacakge) {
            msDeployCmdArgs += " -dest:auto";
        }
        else {
            msDeployCmdArgs += " -dest:contentPath=\'" + webApplicationDeploymentPath + "\'";
        }

Because I have a Parameters.xml file for parameterising my ASP.NET Core application the code you linked will choose -dest:auto instead of -dest:contentPath.

[vincent1173]

@taspeotis , thanks for reporting this issue. its a genuine issue and will be fixed.

[vincent1173]

@taspeotis, Can u add <parameter name="IIS Web Application Name" defaultValue="Default Web Site/ASPCore" /> as a workaround in your parameters.xml file?

[mvvsubbu]

Updating logic to check MsDeploy or not ( #3549 )

[sandorfr]

@vincentdass I can confirm that the issue is fixed as far as I'm concerned (with 2.0). We were using the command (as described here).

dotnet publish -c $(BuildConfiguration) -o $(Build.BinariesDirectory)\WebPublishOutput

And it now deploys just fine without any extra steps.

Thanks.