I am using vs 2012. in the Active solution configuration dropdown list, I have 3 configurations there ("Dev", "QA", "Production").
when I run this application locally, and "QA" is selected as Active solution configuration. I still have local connection string, not the qa one. my understanding is it should use the QA web.config file. am i wrong?
my understanding is it should use the QA web.config file. am i wrong?
Actually you are wrong. web.QA.config will be used only when you publish your application but not while running it in Visual Studio where the standard web.config is always used.
Related
I am having a problem with the configuration manager in Visual Studio 2013. The Deploy column is disabled no. The only thing I did was a Repair of Visual Studio 2013 and not my WebAPI project not longer has the Deploy option enabled in Configuration Manager. I used to be able to do a file system deploy to the folder on the Web Server that hosted my WebAPI process. I am not sure what is going on. Any assistance would be greatly appreciated.
FYI - The CGSAPI project type is class library but that is what it has always been.
OK so I was just being silly. I have to right mouse button click on the actual WebAPI project and Publish will be available in the dropdown list. :)
We have several Web Apps and WebJobs with different configurations for different environment, e.g. Test and Release.
Each WebJob is deployed to a Web App using "Publish as Azure WebJob" in Visual Studio.
We are using the Config Transform extension to transform the App.config that consist of different config sections, connection strings and app settings that needs to be transformed. This works fine for local Debug and for Release.
The problem is that when we use "Publish as Azure WebJob" there is no way to specify which configuration to use and Release is always built and published even if Test is selected inside Visual Studio.
We have also tried to deploy the WebJob together with the Web App but it almost always hangs, same as described in Stuck when publishing Web App to Azure with WebJob
We don't need to use config transform if that's not possible, e.g. we could configure directly in Azure. But I haven't found a way to configure config sections directly in Azure.
Yes this is a known VS tooling pain point that comes up often. The short answer is that web.config style transforms aren't supported for general application types like Console apps.
This has been discussed recently in the context of WebJobs in our public repo here. That issue also links to the VS User Voice issue for this. That item also links to the SlowCheetah VS extension which some users have said works for them. You might give that a try.
If that doesn't work for you, then you'll have to manually manage your settings via the app settings blade in the Azure portal.
I added a prebuild step to change the webjob-publishing-setting.json file and the app.config file depending on which Configuration is selected.
The webjob-publishing-settings.json only had the name. Then from Visual Studio 2019 I used "Publish as Azure WebJob" and that created a second webjob with the new name and new configuration.
Works great!
I am trying to set up my WCF service (.svc) to work in Visual Studio 2010 (pressing F5 to debug), but also to have multiple configurations for each environments (DEV, QA, UAT & Prod). When I originally built the WCF it was used purely in Visual Studio 2010 using .Net version 4 and debugging the service was easy enough by adding a WinForm application to pass in the values needed. When it was time to test the service on a server, I used the Publish feature to put the files on the DEV server and noticed that since it was using IIS that a web.config was created in the base directory.
So now that we are moving on to QA and UAT I need to make sure we have the configuration files for each environment as the Uri's change as well as various other values. Now after searching for a few days on Google, I have tried to use the XDT Transformations, but without having a third party add-in like SlowCheetah, this does not seem to work as it is only built for Web Applications. I have also tried to set up a post-build event to copy different configs:
copy "$(ProjectDir)Config\web.$(ConfigurationName).config" "$(ProjectDir)web.config" /Y
The copy process is set in the Build Events --> Post-build event command line textbox, however this does not seem to work when I use the publish method. I am ok with using multiple config files and copying them, I just have not had success with this.
The XDT makes the most sense to me and would be my preference if I could get it working. The main issue I am having is that it needs to work in Visual Studio, but also to work via IIS on the servers without having to go through a bunch of steps per environment. This is a company rule that I have to follow as well as not having a third party plug-in/add-in.
Is it possible to run the service in IIS and create a servicehost via code? I don't think it is as I believe the MSDN docs say that IIS creates it for you no matter what. Part of my reason wanting to do different configs is so that the page the user gets when they view the .svc file in the browser has the correct Uri in it not the machine name version.
TIA
EDIT: Setting up a dev web.config and including it in the project and then setting it to Build Action: Content fixes the copy method, so technically I have it working as long as I have completely different web.config files for each environment and an app.config for debugging (F5 in Visual Studio).
We've recently upgraded to Visual Studio 2013 and we're having some issues with the new way publishing is handled. Previously, (in VS 2010) every user had their own local publishing settings, but in VS 2013 it's changed to the idea of shared publish settings. This is causing problems with our environment because every developer has a different local dev environment (paths, connection strings, email addresses to send things to). I realize this is not the optimal way to have things set up, but that's the reality of our situation right now.
We use config transforms to handle the various web.config changes for different developers, so just running through VS doesn't work for us because it doesn't run the transforms. This also causes a problem with the VS 2013 publish settings because the last build config used is stored in the shared publish settings. In order to keep all our settings different, it looks like we're going to need to have a different publish setting for each developer now as well (such as "Local - Erik", "Local - OtherDev"). This is just going further down a path I'd like to get out of eventually.
So my question boils down to: Is it possible to somehow disable the shared profile settings? I thought of just not including them in version control, but then Visual Studio complains that the files are missing on other developers' systems.
Thanks for the help!
You can do this by excluding the profile from the project after you create it. The publish wizard looks for any profile on disk, but newly created ones are added to the project by default. If you then exclude the .pubxml file from the project and remove it from source control, it shouldn't bother you again.
I am using CruiseControl.Net for my continuous integration process. Using ccnet I build and publish my asp.net application into a server in Release mode. But I am not able to change debug="true" to debug="false" in my Web.Config during publishing. What can I do?
You might consider using a Web Deployment Project (WDP) which can be run as part of your visual studio build configuration. The WDP will handle things like toggling the debug setting and it change any environment-specific web.config settings as well. Here's a WDP tutorial.
If you are calling a msbuild script from ccnet you could use the XmlUpdate task from the MSBuild Community Tasks Project.
<XmlUpdate
XPath="/configuration/system.web/compilation/#debug"
XmlFileName="$(WebConfigFileFullPath)"
Value="false" />
I documented my build process here if you are interested.
Expanding on Tom Brothers' answer above, we use the <XmlMassUpdate> task in MSBuild Community Tasks to merge a deployment-specific web.config that contains multiple changes to apply to the base web.config to change the debug setting, connection strings, logging configuration, etc. So a web project contains web.config with the configuration necessary to run from the development machines. There's also web.Release.config file which contains only the changes that we need to apply to web.config to produce the configuration on the production web server.
Since the extra file only contains changes (deltas) to apply to web.config, it's not very big. Visual Studio ignores it during development, and CruiseControl.Net applies the changes to web.config when it gets deployed to the web server.