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.
Related
I have created a SharePoint app in SharePoint online in visual studio. This consists of a client web part and a web app hosted in Azure. I have set up a development site and successfully managed to get the app to run. it's just basic at this point because I am more interested in determining how to get it into sharepoint.
But now I am trying to get that app into another site I am having major hurdles. Here are the steps I have taken.
I have deployed the web project. I am assuming this is successful since it shows the changes I make in the development site. I can't imagine that any settings need to be changed for deployment to another site since this deploys to the web app in Azure (I think)?
So the next step I do is Package the App to send to sharepoint online. The potential problems here are that I use the same ClientID and Client Secret I used for my development site. From what I have read this should be handled in the packaging process and no changes need to be made as I try to push the app into the new site. So I am assuming the clientID is not site specific?
So once I have that as a .app file I go to the newly created AppCatalog Site and upload the file.
Once uploaded I can see it in the product ID list as below.
Then I go to our test site and try to pull the app. As you can see it has a message under the app 'You can't add this app here'.
When I click on 'find out why' I get the below message.
I have been unable to find an answer on the web that explains what to do. It's very frustrating and have spent about 8 hours trying to figure this out. I'm sure it's some setting somewhere that needs changing, but don't know what that setting is. Can anyone help?
I am going to go ahead an answer this to save some poor soul in the future. The problem was with the App Manifest file. I had the Permissions => Scope set to Site Collection. This needs to be changed to 'Web'.
We've recently launched a new website in Azure (i.e. Azure Websites) and as is typical with new launches we've had to deploy a few tweaks to fix minor issues shortly after launch.
We want to use Slots in the long run but this is not possible at the moment. Hence we are deploying to the live site. It's a fairly busy site with a good amount of traffic and obviously want to keep downtime to am minimum.
We are using Visual Studio to publish file changes to Azure but have noticed that even if we publish a relatively insignificant single file the whole site goes down and struggles to come back up. I was assuming that publishing a single file would literally just replace that file on the file system but it's behaving more like it recycles the application pool (or Azure equivalent) for the site. The type of files I've been publishing have been Razor views, hence would not typically cause a recycle.
Does anyone know what actually happens under the hood of VS Publish and if there is a way to avoid this happening?
Thanks.
I just tried this using a basically clean new MVC app (https://github.com/KuduApps/Dev14_Net46_Mvc5), and I did not see this behavior. The Index.html view has a hit count based on a static, which would tell us if the app or the page got restarted (or if that specific page got recompiled).
Then the test is to publish it, make a change to some other view (about.cshtml), and publish again. WHen doing this and hitting Index.cshtml, the count keeps going up, and there is minimal slowdown.
If you see it getting restarted after a view change, I suggest using Kudu Console to look at the files in site\wwwroot before/after the publish, and check what has a newer timestamp (e.g. check web.config, bin folder, ...).
I'm using Publish/Web Deploy to deploy an asp.net aplication from Visual studio 2010. It works perfect, but there is a problem. If the new release is not working as expected, the old version is already replaced by the new one and there is no easy way to roll back to the working version. How is this best solved? I wish it was possible to keep the old version on the server so I could just switch back if needed.
With WebDeploy there is no built in rollback feature, so once you've deployed that's it.
There's a number of hand rolled strategies you could put in place, for example:
Limited Access e.g. Shared Hosting:
Where you don't have full access to the machine -
Backup the live site beforehand by downloading it.
Keep copies of what you deployed so you can push the previous version should something break
Full Access:
Maintain two sets of folders for the application and map your site to one or other of these folders. When you come to deploy switch the IIS site's physical path to the other folder then deploy. If the site fails then just knock the site back to the original folder. Each successful deploy would alternate between these two folders.
For stuff like user uploaded content you'd need to map virtual directories to a place on the file system that's always the same place because you don't want to be copying these around each time.
You're not the only one who has encountered these issues. Have a look at this article by Rob Conery and his observations about the state of affairs regarding ASP.NET deployment.
ASP.NET Deployment Needs To Be Fixed
Getting Constructive On ASP.NET Deployment
Using some form of Source Control would be another alternative. We use subversion, so if the publish goes bad, we can just update back to the last-good revision, and publish that. Even if you're the only developer, using source control can be very useful.
My company are working at Sharepoint site that we are developing using Visual Studio. The actual installation at the customer is performed by scripts deploying the produced wsp-files. During normal development I mostly use deployment from directly from inside Visual Studio. Unfortunately I often run into problems when trying to deploy my solutions. We are using a server-farm set up, but each developer has their own virtual server, datebase instance and so on.
We have one project file that the define the basic content-type used for different department. This content-type typically define stuff like what period that the list item cover. Each department have their own project that uses the content type combined with department specific fields to form the final list.
One of my current problems is that when I make edits to the content type and deploy it the changes does not seem to propagate. Even though I rebuild the solution and deploy both the base project and the department project with success I still see the old version of the content fields when I create a new department list. Sometimes it helps to retract the projects, but often I literally have to restart everything before it works.
My question is if this problem is caused by Visual Studio not really deploying my new defintions or if there is some architectual aspect of Sharepoint 2010 that might prevent the change to propagate. What steps can I take to lessen the likelihood of the problem occuring?
Have you tried deleting the content type with Central Administration before doing a new deployment? I've found out that Sharepoint don't update/create content types when it finds other one with the same name.
I'm building an application which will be run on Azure. My Visual Studio solution contains multiple Azure role projects. When debugging locally, I use the Azure compute emulator.
To start debugging, I follow these steps:
I right-click on my Azure project and click Set as start up project.
I press F5 to start the debugger.
What happens now is that the emulator/vs2010 launches both my web roles and worker roles, even if I'm only interested in debugging a single worker role at the moment. Often when writing some background-processing code in my worker role, I'm interested to step through that code without starting the web role, launch Internet Explorer and so on as well.
Is there a convinient way to make the debugger only launch one of the role instances and not all of them?
I'm thinking of creating a separate project in my solution of type Console Application, where I load the same assemblies as in my worker role and execute the same code.
The emulator (similar to Azure itself) works just on the concept of a "Cloud Service". So when you launch w/ debug, its going to launch whatever is defined in your Cloud Service (.ccproj) project. This mimics Azure 100% which is why it occur, but I can definitely see where your scenario would be helpful.
Few options, based on your needs.
If you need to test azure-specifics (aka it has to run in the emulator)
Create a second solution file, create a new Cloud service in here, add your project. I like this option because the projects/roles themselves remain untouched.
What Stuart suggested before me, create a second Cloud Project, set as startup, run that.
Similar to above, create a second project, but don't worry about startup. You can right click on any project, go to Debug and select start w/ debugging and achieve what F5 does without binding F5 to this solution
If you dont need to test azure-specifics (ie you are just testing the role)
Right click on the role's project, Debug, Start with Debugging This way the whole solution remains intact and you are just testing the logic
I think you can do this by:
create a new Azure Cloud Project within your solution
add just the one worker role to that cloud project
set that cloud project as your startup project
This will single out just the worker you are interested in
An easier solution would be to open the ServiceConfiguration.cscfg file, and set the "Instances > Count" property to "0", for all the roles that you don't want running (this only works in the compute-emulator, and NOT on the azure cloud).
That way, you keep your solution intact and your configurations safe, while just omitting them from the compute-emulator during run-time.