I am having trouble changing the publish variable within web.config because it amounts to nothing.
Once I set the variable in web.config to Development, for example, when I launch the application, it still says that the environment variable is Production.
As you can see below, the web.config states that I have set the variable to Development.
I am out of ideas and genuinely unsure whether variables can be set this way anymore.
Looking at your first screenshot, it looks like you are running your application from the command line, probably using dotnet run. In this case, you should note that the web.config is completely ignored.
The web.config is only to configure IIS for when you actually deploy your application on IIS. If you run it in any other way, the web.config is not being used and you will have to configure the environment in a different way.
If you want to run the application from the command line, you can set the environment variable using set:
set ASPNETCORE_ENVIRONMENT=Development
dotnet run
If you use a standard ASP.NET Core template, there should also be a launchSettings.json file which configures the default launch settings. If you specify the environment there, dotnet run will automatically pick it up when you run the application from the application’s root directory.
Related
I have "Development" set in my web.config, in the launchSettings.json (all profiles), and in the environment variables on Windows, but the application still shows the environment as "Staging". Also, even if I run Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") in something like RoslynPad, it also shows "Staging". I do not know where else I can look to set this value. Thank you.
The Environment Context is still "Staging".
As Rena suggested, restarting VS helped fix the issue, and ensuring I did a clean and removing any/all environment variables defined on the OS now allows me to change the environment using the web.config.
I need some environment variables for my project. I placed it in the launchSettings.json as described here. I know it is VS-specific feature but it works fine with dotnet run cli command and it looks good for me. However it doesn't work for dotnet publish command. How should I set environment variables for production? I'd like to place it inside the project without using powershell, docker etc.
The entire purpose of using environment variables is so that they are not part of your project. If you want them to be in your project, then just use appsettings.json. That's what it's for.
I am trying to setup a CI process with Team Build and VS2012. I've setup the web server to accept web deployment. I've installed Web Deploy 3.0, IIS Management Services and have configured the permissions to the website dir.
I have a msbuild project that compiles, packages and then deploys the site using MSDeploy but I'm coming across a issue that seems to be happening to many but I haven't been able to find a clear answer.
The problem stems from needing to pass in the site name to MSDeploy so that the user the build server runs under can publish. Like so:
https://computername:8172/msdeploy.axd?site={websitenameonly}
I've tried various ways to include this in the MSBuild file but they all end in failure. The '=' seems to break the string and cause the {websitenameonly} to be considered as another parameter.
Has anyone successfully been able to pass in the site name via MSBuild?
The MSBuild scripts will append ?site for you, so there's no need to do it yourself.
Make sure you've set the following in your pubxml:
MSDeployPublishMethod is WMSVC
MsDeployServiceUrl is in the format https://computername:8172/msdeploy.axd
DeployIisAppPath is set to your IIS site name
You haven't set NormalizePublishSettings to false (I doubt you have, but worth checking)
I am setting up TeamCity to deploy our Website Project application (using a *.wdproj) and Web Deploy application to IIS.
I have a build configuration that uses MSBuild.exe with the MSDeployPublish to build and then deploy the application.
We now want to get the application to deploy to multiple target environments, therefore need a way to supply different settings based on the target environment.
I have added a parameters.xml file to the Web Deployment Project, and have verified that the parameters set in here are making all the way through the target IIS server and being correctly applied - great!
Now what I want to do is have different parameter settings per environment. I was hoping I could use something like the MSDeploy.exe -setParam argument to specify different values for each environment, however I can find no way to get my parameter values into MSBuild via the commandline.
I suspect I might need to do one of the following:
Split MSBuild and MSDeploy into separate build steps.
Configure a task somewhere in the pipeline to take 1 of n versions of parameters.something.xml and move it into parameters.xml so it gets picked up by the rest of the pipeline.
I'm looking for the simplest way to move ahead at this point, any suggestions welcome.
For reference, here is the command I'm experimenting with now:
msbuild /target:MSDeployPublish MySite_deploy.wdproj /P:Configuration=Debug
/P:DeployOnBuild=True /P:DeployTarget=MSDeployPublish
/P:MsDeployServiceUrl=www.myserver.com:8172/MsDeploy.axd
/P:AllowUntrustedCertificate=True /P:MSDeployPublishMethod=WMSvc
/P:CreatePackageOnPublish=True /P:UserName=MyUser /p:Password=MyPassword
/P:DeployIisAppPath=www.myserver.com/MySite
/P:ServerURL=http://www.tryingtoforcethis.com
It's working beautifully except the value for ServerURL, which is a parameter I've defined in my parameters.xml, is not making its way into the target site. The default I specified in parameters.xml, however, is. So I know that the parameters are working, I just can't figure out how to add them to the msbuild commandline.
Well, I think the short answer is that with MSBuild 4.0 and VS2010, you can't just pass arbitrary parameters into MSDeployPublish from the call to MSBuild.
I found these posts helpful:
http://forums.iis.net/t/1167657.aspx/1 - Ming Chen's comments
http://www.hanselman.com/blog/TinyHappyFeatures3PublishingImprovementsChainedConfigTransformsAndDeployingASPNETAppsFromTheCommandLine.aspx - the comments from Richard Szalay at the bottom
After reading these, and sifting through the Microsoft.Web.Publishing.targets file for some time trying to find a "way in", I finally settled on having multiple copies of Parameters.xml in my project folder in source control, labelled according to their environment eg:
Parameters.Test.xml
Parameters.Staging.xml
Parameters.Live.xml
Then, prior to the package and deploy, I just copy one of these files into Parameters.xml and it gets picked up by the rest of the pipeline - done!
BTW I had a temporary problem getting the parameters.xml copy and subsequent cleanup to work within a single MSBuild.exe call due to what seems to be some sort of file access issue, I've detailed it here:
MSBuild.exe Copy task not working properly unless a version of the file already appears in target
To answer your question, the parameterization of your command line is not a concern of MSBuild. Instead, you should utilize external tools. For example, if you run your msbuild command from a batch file you could pass the parameters to the batch file and run it for each environment with different parameters. Another approach is to use a build system like TeamCity or VSTS and utilize their parameterization mechanism. Adapted for the VSTS or TFS, your command could look like this:
msbuild MySite_deploy.wdproj /target:MSDeployPublish /p:Configuration=Debug
/p:DeployOnBuild=True /p:MsDeployServiceUrl=$(IIsHostNameIp)
/p:AllowUntrustedCertificate=True /p:MSDeployPublishMethod=WMSvc
/p:CreatePackageOnPublish=True /p:UserName=$(IIsUserName) /p:Password=$(IIsPassword)
/p:DeployIisAppPath=$(IIsSite)
In addition, I would suggest some clean up for your origianl command line:
Using both /p:target and /p:DeployTarget is redundant. Any one of them is enough. Also it could be replaced with /p:WebPublishMethod.
For /p:MSDeployServiceUrl it is enough to only provide a DNS name or IP. the port and the Url is automatically derived from the /p:MSDeployPublishingMethod=WMSVC.
The custom parameter /p:ServerURL is unknown and won't be mapped anywhere.
msbuild.exe {build-script.proj} /property:{someParameter=someValue}
In your build script you can use $(someParameter) as a variable
I have WCF library project which I have recently done some minor refactoring on eg changing the namespace and changing it location on disk. I also removed the app.config, because I thought the app.config is used by whatever hosts the wcf service.
I have since noticed that I can no longer debug the library using the WcfSvcHost like I used to be able to do. The message I get from Visual Studio is:
'A project with an Output Type of Class Library cannot be started directly.
In order to debug this project, add ana executable project to this solution which references the library project. Set the executable as the startup orject.
I don't want to do as it says, because I didn't need to do this before. Please let me know how to restore the ability to debug it using the WcfSvcHost. On the Debug tab of the project settings, the Command line arguments is still set to: /client:"WcfTestClient.exe"
Not sure what else to try, thanks.
I have observed that changing the output path of the project cause this behavior. To re-enable the debugging using WCFSvcHost/WCFServiceClient leave the output path to default and it should work.
If you changed the project output path you can still run it, you just need to provide some extra parameters to WcfSvcHost like this (enter this in Command Line Arguments in project's debug settings):
/service:ServiceInterface.dll /config:application.config /client:"WcfTestClient.exe"
No need to enter the full path as it will be run from your new project output path
If you still get the 'A project with an Output Type of Class Library cannot be started directly' then you can try changing the start action to 'Start external program' and select the WcfSvcHost.exe in there
You need to build the project in Debug Mode in order to use WcfTestClient and WcfSvcHost
In Debug mode you don't need another project. The Wcf Service Library runs in WcfSvcHost
However if your solution has only Wcf Service Library you need the app.config to configure the endpoints and etc...