In several projects’ App.config file, there is a line
<add key="url" value="http://www.example.com/"/>
Upon each build, I want to have a task to verify that the "url" key does not have the text "http://localhost". Is there a way to do this?
I'm assuming you have a team, and some of your team members inadvertently checkin those configs, changing that value to localhost.
If this is the case, why not have transform files for each environment, where your debug configuration can set the key to localhost, and your production/test/stage/qa/whatever configuration can set it to example.com or something else.
You might not have been aware that msbuild can transform your config files. Essentially you have your main config file, and then a config file containing just the things changed, for each environment. Upon doing a build, msbuild will modify the main one with whatever the changes are in the other "transform" files.
App.Config Transformation for projects which are not Web Projects in Visual Studio 2010?
Your transform file would look like:
<?xml version="1.0"?>
<!-- For more information on using web.config transformation visit http://go.microsoft.com/fwlink/?LinkId=125889 -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<appSettings>
<add key="url" value="http://www.example.com/" xdt:Locator="Match(key)" xdt:Transform="SetAttributes"/>
</appSettings>
</configuration>
The microsoft link is to http://msdn.microsoft.com/en-us/library/dd465326(VS.100).aspx
They can easily be used on web.configs, as well as app.configs, with a little tweaking to your project file.
An alternative solution would be to integrate unit tests as part of your build, and have the test verify the key in your web.config.
Go to your builds:
Right click on your build and click on edit build definition:
Choose process:
Now we can set fail on build here:
Related
We have a very strange problem with our VSTO Add-In.
In our Add-In there are label controls that read label text values from an app.config file and display text from the configuration file to the user:
<!-- app.config -->
<configuration>
<configSections>
...
</configSections>
<!-- start applicationSettings -->
<applicationSettings>
<OurVSTOAddIn.MySettings>
<setting name="ackMsg" serializeAs="String">
<value>Some text here that we want to display and change</value>
</setting>
...
<OurVSTOAddIn.MySettings>
</applicationSettings>
</configuration>
'vb.net code
objCheckDialog.lblAttachmentsMsg.Text = My.Settings("attachmentsAckMsg").ToString()
objCheckDialog.lblAttachmentsMsg.Visible = True
We recently updated the app.config file to replace English display information with Kanjii for our end-users in Japan.
When we rebuilt the MSI and installed on our test machine, the add-in isn't displaying Kanjii (although it display correctly in development).
Now we're wondering if the configuration file in the installation directory is being read at all or if the information is cached or the add-in is reading from another file somewhere.
What's even more strange is that we've changed other values in our app.config file that are being used in code logic, and these seem to load properly.
We're currently using Procmon in an effort to find out how the config file is loaded, however, while filtering on the following:
Process Name contains Outlook
Path Contains "OurOutlookPlugInName"
This produces over 400 results but we don't see any file handling for our config file unless I debug the code in Visual Studio.
On our installation machine, we also removed the configuration file from the installation directory thinking this might be a clue as to whether the Add-In is reading the configuration file from the installation directory, but it had no effect, and the Add-In loaded normally displaying English instead of Kanjii again.
All of the configuration settins are at the Application Level.
Is there a way for us to tell where our Add-In is loading our configuration file from?
Have we done something incorrect in our MSI build that would prevent the updated configuration file from loading?
UPDATE:
I opened the dll file in the C:\Program Files (x86)\OurVSTOAddIn installation directory using Telerik JustDecompile to see if the configuration settings were written somewhere in the dll and I can see that under OurVSTOAddIn->My Settings there are definitely DefaultSettingValues there, as shown below:
This would make sense since these are Application Scoped Settings and this would prevent a user from changing config settings.
But I'm thinking if we use Application Scoped variables, each time we'll need to rebuild the msi for release, which doesn't make sense to me since the reason we want to use configuration settings for the project is to not need to rebuild for configuration changes.
Overview
I am building a deployable web package that can be imported into IIS that automatically prompts for settings needed by my ASP.NET Core application. I already created a package that will deploy just fine, except after deploying, I need to manually find/edit my appsettings.json file.
I know this package can include a parameters.xml file that will automatically prompt and fill in my appsettings.json when importing an app into IIS. I have already made a parameters.xml file, and manually added it to my package after building it; it worked as expected. I'd just like to have msbuild automatically add the parameters.xml file to the package for me.
A separate project of mine (ASP.NET MVC 4) already does this. For that, I simply needed to put my parameters.xml in the same folder as my .csproj. I tried doing the same here, but had no luck.
Repro Steps
I created an ASP.NET Core Web Application
Using .NET Framework on ASP.NET Core 1.1
I then went to publish my website
Selected 'Folder' (just to get a template)
I then edited the profile and changed the WebPublishMethod to Package and added the three lines below it.
<DesktopBuildPackageLocation>bin\$(Configuration)\$(MSBuildProjectName).zip</DesktopBuildPackageLocation>
<PackageAsSingleFile>true</PackageAsSingleFile>
<DeployIisAppPath>External</DeployIisAppPath>
I then published one more time. Now I get a WebDeploy package that I can deploy to IIS.
Great! but...
I'd like to customize the parameters.xml.
For previous projects, I was able to add a parameters.xml file to my project root, and VS/msbuild would automatically add it to my published package. This currently works for a different project using ASP.NET MVC 4.
So, I tried the same thing for this project. First I added a settings.json with a very simple setting:
{
"SettingName": ""
}
Then I added a parameters.xml file that I know works to my project root. (If I manually replace the parameters.xml file in Sample.zip package, it correctly prompts and replaces my setting when deploying)
<parameters>
<parameter name="IIS Web Application Name" value="External" tags="IisApp">
<parameterEntry kind="ProviderPath" scope="IisApp" match="^c:\\users\\joshs\\documents\\visual\ studio\ 2017\\Projects\\Sample\\Sample\\obj\\Release\\net461\\win7-x86\\PubTmp\\Out\\$" />
</parameter>
<parameter name="Setting Name" description="Enter a custom app setting" defaultValue="Default Setting Value">
<parameterEntry kind="TextFile" scope="obj\\Debug\\net461\\win7-x86\\PubTmp\\Out\\appsettings\.json$" match="(?<=\"SettingName\"\s*:\s*\")[^\"]*" />
</parameter>
</parameters>
Again, I right click and Publish once more. This time with the parameters.xml file.
I expect the Sample.zip to contain the parameters.xml that I added to my project root, but it does not. It is the exact same as from my original publish.
Question
During the build process when creating a web deploy package, how do you include custom settings in the parameters.xml?
I have already tried this...
I already looked at https://stackoverflow.com/a/46338042/2494785, but with no luck, though my command differed slightly from the original poster.
PS C:\Users\joshs\Documents\Visual Studio 2017\Projects\Sample> & 'C:\Program Files (x86)\Microsoft Visual Studio\2017\E
nterprise\MSBuild\15.0\Bin\MSBuild.exe' .\Sample.sln /t:Sample /p:DeployOnBuild=true /p:PublishProfile=FolderProfile /p:
ProjectParametersXMLFile="C:\Temp\parameters.xml"
I was able to solve this from peteawood's comment from an issue posted on GitHub.
https://github.com/aspnet/websdk/issues/201#issuecomment-349990389
In ASP.NET Core 2.0+ you can add the following to your .csproj
<Project Sdk="Microsoft.NET.Sdk.Web">
.
.
<Target Name="AddMoreParameters" AfterTargets="_CreateParameterFiles">
<Copy SourceFiles="Parameters.xml" DestinationFiles="$(_MSDeployParametersFilePath)" />
</Target>
</Project>
SourceFiles should point to the location of your parameters.xml file from the perspective of the .csproj file. My parameters.xml is found in the same directory as my project file.
I believe I can just pass parameters via cmd-line as properties for msbuild.
It's not fully what you asked for I understand.
For example, in the following command I'm passing DeployIisAppPath property:
dotnet publish /p:WebPublishMethod=Package /p:DeployIisAppPath=mysite/myapp /p:PublishProfile=rnddev03-core-dev
and in the output folder we'll get xxx.SetParameters.xml file with:
<parameters>
<setParameter name="IIS Web Application Name" value="mysite/myapp" />
</parameters>
I can't get MS Build to output a transformed Web.Config file. I've setup the build project using NuGet package restore as described in the NuGet docs. Every part of the build works (package restore, CI, web deploy packages) except for the transform. I have tried the base setup and a custom project file as well as lot of other options and I haven't gotten anywhere.
I've done config transform setups before without issue. I have Slow Cheetah installed and can preview my current transform and see that it works. When I run the build locally via MSBuild.exe, the transform actually happens:
TransformWebConfigCore:
Transforming Source File: G:\MyProject\Web.config
Applying Transform File: G:\MyProject\Web.Debug.config
Output File: obj\Debug\TransformWebConfig\transformed\Web.config
Transformation succeeded
(If I look at the -v output I can see the individual transform run)
Then Web Deploy parameterizes my web.config:
Transformed Web.config using G:\MyProject\Web.Debug.config into obj\Debug\TransformWebConfig\transformed\Web.config.
PipelineTransformPhase:
Publish Pipeline Transform Phase
PreAutoParameterizationWebConfigConnectionStrings:
Creating directory "G:\MyProject\obj\Debug\CSAutoParameterize\transformed\Views\".
Copying obj\Debug\TransformWebConfig\transformed\Web.config to obj\Debug\CSAutoParameterize\original\Web.config.
AutoParameterizationWebConfigConnectionStringsCore:
Transforming Source File: G:\MyProject\Views\Web.config
Applying Transform File: <?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add
connectionString="{% token='$(ReplacableToken_#(parameter)_#(tokennumber))' xpathlocator='name' parameter='$(name)-Web.config Connection String' description='$(name) Connection String used in web.config by the application to access the database.' defaultValue='$(connectionString)' tags='SqlConnectionString' %}"
xdt:Transform="SetTokenizedAttributes(connectionString)" xdt:SupressWarnings="True" />
</connectionStrings>
</configuration>
No element in the source document matches '/configuration/connectionStrings'
Not executing SetTokenizedAttributes (transform line 6, 15)
Output File: obj\Debug\CSAutoParameterize\transformed\Views\Web.config
Transformation succeeded
PostAutoParameterizationWebConfigConnectionStrings:
Auto ConnectionString Transformed obj\Debug\TransformWebConfig\transformed\Web.config into obj\Debug\CSAutoParameterize\transformed\Web.config.
The parameterized file is then moved into the package and the transformed file is deleted.
Copying obj\Debug\CSAutoParameterize\transformed\Web.config to obj\Debug\Package\PackageTmp\Web.config.
Deleting file "obj\Debug\CSAutoParameterize\transformed\Web.config".
So I have a transformed web.config file that doesn't end up in my build output. Why does the transform happen but not get copied to the output directory or the web deploy package?
I had the same issue here. This is caused by the Web Deploy Pattern. It uses the "project name".SetParameters.xml in the Web_Package to replace values on Deploy.
Since you want to use SlowCheetah you need to circumvent this.
You can accomplish this by replacing the connectionstrings setting in your web.config by:
<connectionStrings configSource="connectionStrings.config">
</connectionStrings>
Of course you will need the connectionStrings.config file. You van create this manually and put in the originasl connectionStrings section.
The node should be the only node in the file.
Now you can add SlowCheetah Transform on your connectionStrings.config file.
I've been using web.config transforms for a while now, for deployment on a few of our projects. What I'm now trying to achieve, is to have Web Deploy's 'Import Package' screen to prompt to check & update several of the variables in , adjusted for each environment.
I know I can use Parameters.xml to introduce these editable variables, but I haven't yet found how to have the defaults updated for different environment targets.
Consider the following neat, but non-overlapping example of wanting to have the user edit the 'specialServer' AppSetting, and have it present a different default when compiled for the NewEnv target:
Sample entry in Parameters.xml:
<parameter name="Special server" description="" tags="" defaultValue="server1-dev.domain">
<parameterEntry kind="XmlFile" scope="\\web.config$" match="/configuration/appSettings/add[#key='specialServer']/#value" />
</parameter>
Sample transform for Web.NewEnv.config, setting a different value for
<appSettings>
<add key="specialServer"
value="other-server.domain2"
xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>
Sample of the prompt in Web Deploy:
Any suggestions as to how to update the default value for different build targets?
Thanks.
You would have to generate and new parameters definition file and embed it in your WebDeploy package for each environment.
This would give you different deploy packages per environment and would allow you to specify different default values for those parameters. Obviously doing so undermines the point if parameter transforms and you essentially end up baking in your config, but it's the only way to achieve what you want.
I don't recommend the approach but it may fit your needs.
We use a batch script to call msdeploy. It allows for a parm to specify the Parameters.xml file. Then with multiple Parameters.xml files (one per environment), you can just call msdeploy like:
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:package='D:\mysite.zip' -dest:auto,computerName="testcomp1",includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"D:\mysite.test.SetParameters.xml"
Using msbuild in .NET 4.0, I can build web project with the "Package" target, and it does a nice job of putting the package in a zip file. But, when I look at the web.config in there, it's not transformed, it has "$(ReplacableToken_Web_SiteConnection-Web.config Connection String_0)"
I can run the "TransformWebConfig" target and it will do the proper transform, but just in its own silo.
I can also run the "Build" target and pass the "DeployOnBuild=True;DeployTarget=MSDeployPublish" properties and it will deploy the package on my server with the proper web.config transform done.
But, if I want to manually deploy the package to the server, how do I do a "Package" with a "TransformWebConfig" so that the zip file has the final web.config in there?
If you want to skip this from happening then you need to set a property in your build. You can do this in two ways
Edit your project file
Create a .wpp.targets file
I would recommend #2. For this case create a new file in the same directory as your project file with the name {ProjectName}.wpp.targets where {ProjectName} is the name of your project. Then inside of this file you should place the following contents.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
ToolsVersion="4.0">
<PropertyGroup>
<AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings>
</PropertyGroup>
</Project>
In this case you are setting the property AutoParameterizationWebConfigConnectionStrings which tells the Web Publishing Pipeline to not insert those {} placeholders in the web.config for the connection strings.
The way we do this is by modifiying the project build to do the transform prior to packaging it up.
The Target is call TransformXml and is a part of Microsoft.Web.Publishing.Tasks.dll
In your own targets its
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
But it will be included in a default VS C# build.
So
<TransformXml Source="web.config" Transform="web.release.config" Destination="$(DeployPath)\web.config" />
Does the trick for us.
Set up those paths with the right ItemGroup ("content" most likely) and make sure that target gets fired prior to the call to Package in your .csproj, and the build output will contain a "Web.config" like normal, with the right transformed values.
Alternatively (we've used this for packages that need to be everything to everyone), you can use that trick to do ALL the transforms and include each of them in the final package.
Then you call Msdeploy manually and use its skip and replace directives (forgot the technical term) to only output the right one at deploy-time
Assuming you have a web.usethisone.config in your package, that looks like
-skip:objectname=filepath,absolutepath=web\..*\.config
-replace:objectName=filepath,match=.*web\.usethisone\.config,replace=web.config