We recently stood up a new Azure account and are in the process of developing a new application to be deployed to it as a web app. While we are able to deploy to our staging slot from Visual Studio 2015, when attempting to deploy an automated build from Visual Studio Team Services (hosted by Microsoft) we are getting the following error:
Get-AzureWebSite -Name $APPLICATION -ErrorAction SilentlyContinue -ErrorVariable azureWebSiteError -Slot staging
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.WindowsAzure.Commands.Websites.GetAzureWebsiteCommand.Do(Action call) in d:\workspace\powershell-publish\src\ServiceManagement\Services\Commands\Websites\GetAzureWebSite.cs:line 138
at Microsoft.WindowsAzure.Commands.Utilities.Common.AzureSMCmdlet.ProcessRecord() in d:\workspace\powershell-publish\src\ServiceManagement\Common\Commands.ServiceManagement.Common\AzureSMCmdlet.cs:line 174
New-AzureWebSite -Name $APPLICATION -Location North Central US -Slot staging
Conflict: Website with given name $APPLICATION already exists.
Publish-AzureWebsiteProject -Name "$APPLICATION" -Package "C:\a\1\a\$APPLICATION.zip" -Slot "staging" -ErrorVariable publishAzureWebsiteError
The website $APPLICATION was not found. Please specify a valid website name.
Cannot get website, deployment status is not updated
This is a fairly significant issue since it is preventing us from using continuous deployment at this time. Are there any work around or configuration settings that we should look at to fix this?
There is a known issue that causes publishing from VSTS to fail if the Web App has VS 2015 Debugging enabled. Can you check whether it is the case for you, and try again after turning off debugging in the Azure portal?
That issue will be fixed soon, so treat this as a temporary workaround.
This was eventually traced back to two problems.
The first problem was that we needed to load up a different management certificate since the one we were using was defaulting to a different account. This goes back to the issue of having one account associated with more than one subscription. At the time of this writing, there doesn't appear to be a way of specifying which subscription to download.
The second problem appears to have been associated with the known bug mentioned by David Ebbo in their answer.
A couple things you can try:
Since you mentioned you have 2 subscriptions, make sure that script you have above is running against the correct subscription, if it's not, it would give the exact error you're seeing. Put a:
Get-AzureSubscription -Current
command at the top of your script and see if that's what you'd expect.
VSTS has a build task for deploying to a web app, can you deploy the package using that task?
Related
I'm trying to make Orchestrator work inside Bot Framework Composer. I'm able to install the Orchestrator extension from packages. When I try to run the bot from inside the composer, I'm getting a self signed certificate in certificate chain error.
However, when I run the bot as a solution from Visual Studio it runs well and the bot starts well in Emulator. When I try to trigger an intent that is using Orchestrator, I'm getting the below error.
Value cannot be null. (Parameter ‘modelFolder’)
Are we supposed to manually download the NLP model that orchestrator uses and place it somewhere ? I'm facing similar issue when I deploy this to Azure. Am stuck at this for a while now. Any help is deeply appreciated.
I've tried a similar setup on my personal machine and don't see the certificate error. The error seems to be because of Firewall/VPN issues at work. Locally, the model gets downloaded to AppData under Users folder and the model path is pointed to that location. Local execution works. I've copied the model data to the project folder and provided a relative path to publish on Azure. While even this setup works locally, however when I publish to Azure I receive failed to load or find model error. Below is a screenshot of the same from Test Web Chat
The catch is that the model exists at the exact place being pointed out by the bot. However, its not able to locate it. I've seen couple of Github issues discussing about the x64 and x86 bit app service regarding Orchestrator. I've deployed this to a x64 App Service with 3.5 GB memory.
Short: How do I create a publish profile in Visual Studio that deploys a deployment slot vs production slot?
Long: That moment when you get a Sev1 call saying that Production is busted and you know that minutes before you just fired off a deployment to your integration deployment slot. Yup that's what just happened to me and for the life of me I can't explain it.
So we have one deployment slot for our Azure Function app named "Int". When creating the publishing profiles, I simply used the "Create new profile" wizard in Visual Studio and chose "Select Existing" Azure App Service, and then drilled in on the "Int" Deployment Slot. Seemed pretty straight forward. Well doing so causes both Int AND Production to be deployed. This was certainly unexpected and obviously catastrophic.
After some digging in the Portal I found in the "Overview" section of our Azure Function app there's a "Download publish profile" button. Clicking it for Production as well as for INT yields two separate files with different users, destinationAppUrls, etc. The only thing that was the same between the two was the FTP publishUrl but I assume that the server would route to the appropriate root based on the credentials passed in.
As it stands in spite of the fact that I have two unique publish profiles, one for prod and one for int, deploying either of them updates both production and our deployment slot.
Here's a list of the things I've tried to fix this myself to no avail:
Deleted both publishing profiles from Visual Studio and recreated them via the Wizard.
Deleted both publishing profiles from Visual Studio and recreated them via the downloaded profiles from the portal.
Deleted the INT publishing profile, created a new FTP user in the portal for our INT deployment slot, updated the downloaded profile for INT, then imported it into Visual Studio. <== Honestly I think this was dumb because I don't think VS is using FTP to deploy. I could be wrong though.
Ensured AutoSwap is turned off.
Used an FTP client to manually login with the publish credentials. Turns out even though Production and Int have different "FTP Deployment Users" logging in as either points at the same location. (This ultimately seems to be the problem)
Clicked "Reset publish profile" on the deployment slot and re-downloaded profile.
Other than losing the autoswap feature which I'm not even losing, I suppose one way to work around this would be to create an entirely separate app thus forcing it to work properly. I really want to avoid that if possible though.
Thanks in advance for help here.
That shouldn't happen, but if I had to guess, you must have the same values for WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined in both apps. The former is the storage account where your app content will be saved, and the latter is the share name in that storage account. It's fine for both to share the same WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, but if you also share the same WEBSITE_CONTENTSHARE, then you'll end up with the odd behavior you're seeing.
Usually when you create the function app through the tooling it should create a new share with a random name for each app. If you deploy using an ARM template or some other method and set these both to be the same you'll run into that behavior.
I'm using the Hosted Agent for release management in Visual Studio Team Services. I have a cURL Upload Files task on my release definition which was working last week and I've had several successful deployments over the past weeks.
Today I created a new release from the same release definition and I am receiving the following error on the cURL Upload Files task.
2016-03-31T08:56:43.4253012Z ##[debug]curl=null
2016-03-31T08:56:43.4263027Z ##[error]curl was not found in the path.
2016-03-31T08:56:43.4303022Z ##[debug]task result: Failed
2016-03-31T08:56:43.4313025Z Return code: 1
I have checked the System Capabilities on the Hosted Agent and it lists curl C:\Program Files (x86)\Git\bin\curl.exe as one of them.
Any one have any ideas why this has suddenly started failing?
First, sorry about this. I'm with the product team and we’ve confirmed this is a regression on our side. cURL is still on the box but it is no longer in the path. We’re working on getting this fixed on our end but it’ll likely take a day or two. In the meantime, we’d recommend doing the following:
Before your curl task, create a new powershell task
Change the type of the task to be an “Inline Script”
Change the Inline Script input to be the following:
echo "##vso[task.setvariable variable=PATH;]$env:PATH;C:\Program Files\Git\usr\bin"
Save and queue a new build.
UPDATE: We've fixed this issue now. The workaround should be no longer necessary.
We are trying to access Test plans using the Web interface from Test Manager 2013 and we keep getting this message.
The test plan with id 328 does not exist or it’s area path is not owned by the default project team.
I read in another post that a fix would be to open the ROOT Test plan in Visual Studio and save it.
I don't know how to do that, can someone please let me know how or point me to somewhere I can learn on how to do that.
I haven't had this problem myself but what another post you mentioned means is following:
Go to Visual Studio
Search for a Work Item with ID from the error message you are getting (in your case 328)
Open this Work Item (it should be a Test Plan) in Visual Studio and save it
According to the post Cannot view any Test Suites and Test Cases in TFS 2013 Web Access despite being able to access them in MTM this should solve your problem.
Update:
What do you see if you just open TFS Web access in browser?
Can you see this "Test" part?
Can you see your Test Plans in the list of test plans of selected *Team Project"?
If you can't see your Test Plans in the list change the Team Project (just click on this and select another one)
Further update:
Please check this article describing new permissions that was added with TFS 2013 Update3: Plan Manual Tests using Team Web Access
You still access test plans and suites using either the Team Web Access or Microsoft Test Manager. But make sure that you set up access based on permissions for the area path.
We didn't have this kind of issues after upgrade to TFS 2013 Update 3 so I can't help you much...
If you don't find nothing helpful in article above consider to contact Microsoft since it seems to be an Upgrade issue.
I think this is a bug in the web access portion of TFS.
If the test plan's area includes a child node, you will get the error. For example: myArea/myChildArea. If you remove the child area, it works in web access. (Test Manager works in all cases.) My guess is that the web access logic is comparing the entire area path name as opposed to just looking at the top node of the area path.
(Problem occurs in TFS 2015)
I had similar problem and i solved it using following option.
Go to Areas on web tool and enable checkbox for sub-areas which selected under test plan, it is recommended not doing it on root areas.
We have a an ASP NET MVC website solution which only one out of three devs on the team is able to publish to the live server. When I, and another colleague, attempt to publish the site from VS 2010, the output window will display an error:
Unable to create the Web site
'\blah'. The path '\blah' does not
exist or you do not have access. The
specified path is invalid.
This points to a logon issue which my account, but the developer who can publish the site is a member of all the same user groups as me. As a long-shot, we gave Everyone full access to the folder, but this did not resolve the problem.
Can anyone suggest a more detailed way to try and figure out why we cannot publish the site? There must be a permission set somewhere that is allowing my colleague to publish the site from Visual Studio.
I had this problem and racked my brain trying to resolve it so I wouldn't have to copy the publish files to a remote server manually. I spent a great deal of time actively trying to get this to work.
Here's how I solved the problem: I went to File>Open in Visual Studio 2010 Express and navigated to the remote server (\\255.255.255.255\folder1\folder2\folder3 and so on). Right away I was challenged for a User Name an Password. I entered the credentials for the REMOTE server, checked the box to 'Remember my credentials'. I immediately tried to publish and voilá - it worked like a charm.
I hope this saves a lot of people a lot of time.
I had this issue - certain members of our team were able to publish directly from VS2010, whereas for some reason I was always getting permission denied errors, even though we were all able to connect to the server we were trying to deploy to. I fixed it in the following way:
Go to "Server Explorer".
Right click "Servers" and go to "Add server..."
Type in the name of the server you are trying to connect to, and then click on "Connect using a different user name..." - put the credentials for logging into the server in here.
Click OK and wait for it to add the server.
Now try and publish to that server and it should be ok...
Not sure why I needed to do this and others were able to deploy without adding the server in this way... remains unexplained.
According to the comments below:
You may need to restart Visual Studio in order for this to take effect.
This should also work for newer versions of Visual Studio
Faced the same problem today. In my situation I had to close VS2010 and open it NOT as an admin and it worked without any problems.
This got me for a long time...Go to Project - Properties and select the Package/Publish Web tab. Under the header "Web Deployment Package Settings", there's a ellipsis button that you can use to map to the location you want to publish. You will be asked for your credentials during that process.
Are you using web deploy (right click and choose Publish)?
Have you tried copying the ProjectName.Publish.xml file from the one machine where you can publish to the other two machines? The login credentials for publishing are saved in this file.
In IIS can you check to see that all users/groups are listed under Management Service Delegation in IIS Manager? It is listed under the Server node in IIS. Alternatively you can give all administrators access by clicking on Edit Features from the side-menu and checking Allow Administrators to bypass rules.
You could also check under IIS Manager Permissions for the individual site to see if the person that can publish is listed under there and you are not.
I just recently setup MSDeploy access on my server and found the following two tutorials helpful:
http://william.jerla.me/post/2010/03/20/Configuring-MSDeploy-in-IIS-7.aspx
http://code-inside.de/blog-in/2011/04/03/howto-setup-of-webdeploy-msdeploy/
I have also found that mapping a drive to the UNC location can be a work around.
#soupy1976's solution has also worked for me.
I can not explain why one day it will work and one day it won't
Frustrating....