Sorry I'm just starting out with Azure, hopefully the following question makes sense.
I have an Azure project with 3 roles. I'd need to deploy one of them right now, but the other 2 roles are far from being ready and I'd have no use in deploying them at the moment (and that would also make me pay for 3 instances, right?)
Would Visual Studio let me deploy just the role I'm interested in?
If not, is there a way to temporarely remove the other roles without losing their settings?
(Thank you for your answer Richard, I was hoping I could — for example — just comment out parts of the ServiceDefinition / ServiceConfiguration files to tell VS not to package the extra roles.)
Just delete the projects you don't want to deploy from the 'roles' folder of your Cloud project, and they should be ignored.
You can easily add them back in when you're ready to use them.
Related
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.
We are new to Windows azure and are developing a Sitefinity web application. In the beginning of the project , we have deployed complete code using Sitefinity Thunder to different environments which actually publish complete code. But now as we are in the middle of development , we are just required to upload any new files created which can be quite less in numbers (1 or 2 or maybe few). Now if we deploy with thunder , it publishes all files and then deploys complete code which takes good amount of time. Is there a way we can deploy only changed or new code files via sitefinity thunder or is there any other way with which we can only upload only the changed files?
Please help.
I use Beyond Compare 3 from scooter software to move files to our different Sitefinity environments. I haven't used Sitefinity Thunder to deploy my sites before. Also, you might want to post your question on the Sitefinity Devs group on Google+. Below is the link.
https://plus.google.com/communities/101682685148530961591
This is not easy to do and Azure is not designed for this although many people have requested this feature. The one way to achieve it is to enable Remote Desktop for the cloud service and then by logging onto the server, you can then make some kind of connection to where your files are stored and copy them into the cloud service. However, it is always possible that the instance will be rebooted and even re-provisioned from fresh so I don't know if there are any guarantees that this is a safe way to do it.
Some background to my problem...
We are currently using ClickOnce to deploy part of our solution which was working a treat until we encountered a scenario where we are now required to have multiple instances of our application installed on the same PC. We are able to achieve this internally and have this working perfectly as we know what instances we have so our build process will update AssemblyName to include the instance name before publishing the installer, this means we are able to have multiple instances on our PCs internally (ie, test, live and demo etc).
Our external deployment process is slightly different, we take one of the ClickOnce installers created in our build (along with all our other components that make up our application) and as the ClickOnce installer is deployed on a server we update the app.config along with the manifest files and resign so they now have client specific details. If a client chooses to have multiple instances of our product installed the ClickOnce will now fail when a second instance is installed on a desktop PC as all instances share the same assemble name.
So finally to the question, does anyone know of a way to update the manifest etc after the clickonce package has been created to allow multiple instances to be installed? We could go down the route of building many clickOnce installers but I dont think this will really work for us, is there perhaps an alternative to ClickOnce which provides a similar upgrade experience for non-admin users?
Hopefully someone will be able to share their experiences and help me resolve this.
Thanks in advance
Doug
I don't know of another technology that allows such a simple auto update process. So sticking with ClickOnce... I think this link might be useful. It explains what you need to do to have the same app installed twice. Essentially changing the assembly name and product name should do it.
Hope that helps.
Greg
Scenario:
In my organisation, we separately develop multiple applications. In the end however, many of the applications (and their databases) are deployed to the same SQL instance, so they share the same master database.
We use Visual Studio 2010 database and server projects to source control said databases.
To try and standardise some things, I want to do the following:
Create a 'Core' Server database project which has all the server settings, core logins etc. Things like SET TRUSTWORTHY ON and server-level ANSI settings etc.
Have each Application's own Server.dbproj specify the logins and roles etc specific to that application.
Have each Application's own ApplicationDatabase.dbproj reference the ApplicationX.Server.dbproj
In theory, each Application in source control would only contain the items specific to it, rather than keeping server related settings or configuration synchronised across many projects.
Problem
However, in practice I can get this far:
Done. Produces a .schema file which I reference in future steps
Done. Server.dbproj happily references Core.dbschema and 'extends' it with it's own logins and roles etc. Is happy to deploy this anywhere I point it.
Nadda. I add a reference from ApplicationDatabase.dbproj to Server.dbproj (assuming Server would pull in the items from Core) and it complains about any logins that are actually in Core.
So I then added both Server and Core as references to ApplicationDatabase as it settled down. Compiles fine.
However, when you deploy, you get the same problem described here: http://social.msdn.microsoft.com/Forums/uk/vstsdb/thread/23cb9132-00d4-42ed-b34c-ab49027cddf7
Error TSD01234: The source model contains 2 server option elements.
Only one element can be contained in a model that can be deployed
The problem I think is that ApplicationDatabase essentially has two Server projects that it knows about, and therefore duplicate settings.
Microsofts documentation makes no mention of using partial projects in Server projects, but neither is it listed as a limitation.
So the question is...
Has anybody used partial projects successfully for Server projects, or is there a way you can see to achieve the same thing?
I'll be honest and say I won't just 'remove the Server projects' to make the problem disappear - we had it working very well up until I tried to improve things!
Do I have to manually edit the Azure connection strings myself to switch between production and development, or is there something comparable to the Transformation Visual Studio applies to Web.Config?
To add to what Brent has said. I use a special small configuration-only (Config) project that contains a folder for every deployment type - inside each folder there is a collection of .config and .cscfg files that are tailored toward a specific deployment (a few partial .config files too). During every compile via Pre-Build event step, Visual Studio copies the files from the correct folder into the root folder of that Config project.
This is the command I use in the Pre-Build Event Command Line:
xcopy /Y "$(ProjectDir)$(ConfigurationName)\*.config" "$(ProjectDir)"
xcopy /Y "$(ProjectDir)$(ConfigurationName)\*.cscfg" "$(ProjectDir)"
Every other project in the solution links to the configuration files from the root folder of the Config project.
I also use config transformations as well, for Production vs. Non-production environments. Everything non-Production (local development environment, Azure-QA development environment) has a lot of debug and tracing built in - errors are returned completely to the clients/etc. Production environment has that locked down.
Edit: wrote a blog about this finally: http://www.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution.aspx
As Brent pointed out, it is not a good idea to have Staging area to be a full-blown Testing site. It is more geared toward a quick smoke test as well as a great way to deploy a new package into Azure without taking your main site down. (IP swap between Production and Deployment usually does not cause any issues to users)
Hope this helps
First a question, are you referring to configuration settings in the traditional configs? Or in the cloud service config (cscfg)?
If the later, then ATM I'm not aware of any support for configuration transformation. The approach I've seen most folks taking is to maintain number configuration files and use the appropriate file when doing your azure deployment.
This subject also touches on usage of the "Staging" environment. I've seen some folks using it as a parallel testing environment. In practice, its more affective to use it as a staging area to smoke test a new deployment before rolling it into production. If you have a need for a longer term test environment, I've found it better to deploy those services to their own unique namespaces that are then sandboxed away from the production services.
This again touches on ALM best practices for Azure (versioning, deployments, etc..). Something I believe the PNP team is working on and will hopefully have recommendations for soon.
Like knightpfhor said, you can use Visual Studio config transformations if you edit the .ccproj file manually. My answer to a similar question lists the minimum number of steps required to get transformations working.
You can use CloudConfigurationManager in Azure SDK 1.7 http://msdn.microsoft.com/en-us/LIBRARY/microsoft.windowsazure.cloudconfigurationmanager
This starts by looking in the ServiceConfiguration.cscfg e.g. ServiceConfiguration.Cloud.cscfg for config setting. If it isn't there it falls back to web.config and app.config
For example
CloudConfigurationManager.GetSetting("StorageConnectionString")
Will look in the appropriate cscfgfile for StorageConnectionString setting, then it will search the web.config and then app.config.
The simple answer to your question is yes, but you have to mess around with the .ccproj file manually to do it. A full description on how to to do this can be found here