I am having a website developed in Visual Studio 2012.
The web.config is currently containing following files in its transformation:
- web.Debug.config
- web.Release.config
I have recently added a new build configuration (named as "Staging") in my project. How can I create a "web.Staging.config" transformation file?
There are two ways for the web.config transform files to be generated within VS:
If you have a web application project, Right-click on web.config and choose Add Config Transform. This will add any config transforms that are missing from your project based on build configurations (i.e. if you have Production and Staging build configs, both will get a transform added).
This method is not supported for Website projects as they do not support multiple build configurations.
In either web project type, right click on a publish profile (.pubxml) and choose Add Config Transform. This will add a new config transform for that profile only.
This requires VS2012 Update 2 or the Azure SDK 2.0 for VS2010 (I think).
In a web site project, the new transform file will not be nested under web.config as VS doesn't support that behavior. Just look for it in the root folder.
IN VS 2012:
Go to Build->Configuration Manager
Click on the Active solutions configuration and select "New".
Enter the name of your new configuration and click Save.
Right click on your Web.config file and select Add Config Transform.
Your new transform file will be automatically created.
You need to first install the Configure Transform extension [Extensions -> Manage Extensions -> Online section] to see the option when right-clicking your web.{environment}.config files.
Related
I am confused about where SlowCheetah looks to determine which transforms to add.
When I go to build/Configuration Manager, I can add new profiles, then go to appsettings.json, right-click, Add Transform, and it will add a new transform (empty file) based on that profile.
However, if I delete the Release and Debug profiles from Build/Configuration Manager, then add transforms again, it still generates appsettings.Debug.json and appsettings.Release.json.
Is it looking somewhere else in addition to Configuration Manager profiles?
The confusion here was due to confusing behavior in Configuration Manager.
If you create a new configuration, in order to delete that configuration, you have to first delete it from the Active Solution Configuration dropdown, then delete it again from project's configuration dropdown (even if they don't have it selected).
Definitely non-intuitive behavior from Visual Studio's build configuration manager.
I cannot deploy using the build created by the integration between Azure and VSO.
The build finishes correctly, but it is not deployed on the website! The bin folder is there. But there is no folder for the views!
I have the impression it started when I create an webjob in the solution.
I cannot publish it neither!
Thank you
It's possible you're actually publishing the web job (is the project just a console app?) to the webapp, instead of the web project.
(Side note, this is one way to get a web job deployed and running)
You can control which project in your solution is being deployed by adding a new setting under "app settings" on the "configure" tab for the webapp.
The setting you want is Project and it's a relative path from the solution root to the .csproj file of your web project.
Alternatively, you can specify the setting in a custom .deployment file.
Relevant Kudu documentation here
From the documentation:
You can specify the full path to the project file. Note that this is not a path to the solution file (.sln), but to the project file (.csproj/.vbproj). The reason for this is that Kudu only builds the minimal dependency tree for this project, and avoids building unrelated projects in the solution that are not needed by the web project.
Here is an example:
[config]
project = WebProject/WebProject.csproj
I just upgraded a Web Site project from VS2010 to VS2012 and I was looking into figuring out how to do what I used to do in the DeploymentPackage projects. There is a lot of good questions and answers I've read through on stackoverflow and I know what to do once I am able to find the files I need. For some reason my web.config doesn't have the two files underneath it (Web.Debug.config and Web.Release.config). I've installed the Web Platform Installer stuff and created my profile. I also created a custom configuration for deployment but I still am unable to see these files get created so that I can start changing some of my web.config settings on deploy time. Does anybody know if there's some setting/trick to get these files to show up in a migrated project?
If you don't see the files web.debug.config or web.release.config beneath the web.config file it could be because they are hidden. In the solution explorer panel if you click "show all files" they should appear.
I found the answer in a post here: how to add files in web.config transformation process?
In your "App Data" folder you'll find your publish profiles you created and can right click on them to add a config transform file.
I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.
Just wondering if anyone knows how to set a saved publish profile as the default i.e. profile that's automatically loaded when I select publish. I love the new profile approach but I'm a bit over having to reselect the same profile over and over while I'm developing.
In VS2012 and up, you can set the Default Publish Profile by right-clicking on the .xml profile file and clicking the Set As Default Publish Profile option. It will then be auto-loaded when you click to Publish the project.
So I've just discovered how to do this, right click on the specific .xml file (e.g. Debug.publish.xml) that you wish to publish and it is automatically loaded into the Publish panel.
Double clicking the XML file also works
The latest Visual Studio 2012 Updates also now include right click options for:
1 - Set as default
2 - Publish
Rob, you may want to consider setting up some batch files that call SQLPackage to use your desired Publish profile. I blogged about it here: http://schottsql.blogspot.com/2012/11/ssdt-publishing-your-project.html
For our dev team, we have a set of batch files set up that can build one or all databases locally from whatever branch they're currently using. That makes it a lot easier to update the local database. The "Publish All" batch file takes a little time to run but is still better than opening each project individually to publish the databases.
Slightly odd issue: I renamed my .xml file to .localdev.xml....file name is "double extension'd" - VS/Datatools looks for ".publish.xml" NOT just the .xml file. In my case I needed "*.localdev.publish.xml". When it had the wrong name the "Set as Default Publish Profile" right click option DID NOT show up, nor did double-clicking...where is Molder when you need him?!?!? ;)
Get the name right, get the right functionality......MS needs better, more creative QA people!! ;)