How to deploy different App.config values (with WiX) - deployment

I've been looking for a best practice recommendation on how to deploy an application with a WiX installer for different values in its App.config file. For example.
On my local development machine, I use App.config settings for our test environment:
<configuration>
<appSettings>
<WorkingDirectory>C:\Working</WorkingDirectory>
</appSettings>
<connectionStrings>
<add name="ApplicationEntities"
connectionString="[TestingConnectionString]"
providerName="System.Data.EntityClient" />
</connectionStrings>
</configuration>
When I deploy to a test environment, those settings are acceptable. However, when we deploy to a production environment, I'd like them to be different. For example:
<configuration>
<appSettings>
<WorkingDirectory>\\prodserver\Working</WorkingDirectory>
</appSettings>
<connectionStrings>
<add name="ApplicationEntities"
connectionString="[ProductionConnectionString]"
providerName="System.Data.EntityClient" />
</connectionStrings>
</configuration>
The answer to my question may very well be independent of WiX. But just in case, here is my WiX Product.wxs file's relavent fragment:
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="ProductComponent" Guid="{MY-GUID}">
<File Id="Application.exe"
Name="Application.exe"
Source="..\Application.exe"
Vital="yes"
KeyPath="yes"
DiskId="1" />
<File Id="Application.exe.config"
Name="Application.exe.config"
Source="..\Application.exe.config"
Vital="yes"
KeyPath="no"
DiskId="1" />
</Component>
</ComponentGroup>
</Fragment>
This setup ends with a manual edit of the App.config on the production server, which invites manual error. What would be a better way to handle this to accommodate an automated deployment?

I can think of two options, either deploy the app.config file and edit it using the XmlFile Element, or maintain multiple app.config files each representing your target environment, then deploy the appropriate file.
Here's an exmaple of both options, notice that I copy the file rather than just placing it on the file system. This serves two purposes, firstly you can see by the filename which one has been deployed, secondly if development.app.config and production.app.config are placed in the same location you will get an ICE30 validation error, by copying the file afterwards it avoids this error.
Notice also that I have a condition associated with the component, you'll need to decide how you identify which environment you are deploying to. Some ideas could be to use the machine name, the OU or simply pass it in on the command line as a property.
<Component Id="development.app.config" Guid="*">
<Condition>DEVELOPMENT</Condition>
<File Name="development.app.config" KeyPath="yes">
<CopyFile Id="development.app.config" DestinationName="app.config" />
</File>
<util:XmlFile
Id="WorkingDirectory"
Action="setValue"
File="app.config"
ElementPath="/configuration/appSettings"
Name="WorkingDirectory"
Value="C:\Working"
Permanent="no" />
</Component>
<Component Id="production.app.config" Guid="*">
<Condition>PRODUCTION</Condition>
<File Name="production.app.config" KeyPath="yes">
<CopyFile Id="production.app.config" DestinationName="app.config" />
</File>
<util:XmlFile
Id="WorkingDirectory"
Action="setValue"
File="app.config"
ElementPath="/configuration/appSettings"
Name="WorkingDirectory"
Value="\\prodserver\Working"
Permanent="no" />
</Component>

Related

nuget.exe ignores inheritance for packageSourceCredentials

Is it possible to configure Nuget so the package sources are configured in the nuget.config file in the solution dir, while the credentials for those sources are configured in the nuget.config file located at the user level (%appdata%\NuGet\NuGet.Config)?
Reading how settings are applied for nuget operations, seems like nuget.config has some sort of inheritance. I was trying to use this inheritance to configure nuget for my team in the following way.
Each developer will have a personal set of credentials to the Nuget repository.
Each visual studio solution will contain a Nuget.config file in the solution directory.
2.1. The Nuget.config file will contain two package sources: nuget.org, and a private credential required source.
Each developer will configure the credentials to the private Nuget source within the file located in the user profile (%appdata%\NuGet\NuGet.Config). In this way, those credentials are not committed to source control.
here are some examples of the nuget.config files I am trying to use:
Solution level file
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/api/v3/index.json" />
<add key="Private" value="url_for_the_private_feed" />
</packageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
</configuration>
User level file
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
<packageSourceCredentials>
<Private>
<add key="Username" value="user_name_here" />
<add key="Password" value="encrypted_password_here" />
</Private>
</packageSourceCredentials>
</configuration>
For some reason, I am not able to get this to work.
I finally figured out that if the NuGet command includes the argument -configFile <path to nuget.config> then the behavior described in how settings are applied does not apply, and instead, the NuGet CLI will only consider the configuration file passed as a parameter.
This is not clear in the documentation. For some reason, I thought that I could pass a nuget.config file to the NuGet CLI, and it would use that file in conjunction with the user-level configuration and the computer-level configuration.

TFS build .net Core with nuget restore end in error

While trying to build on tfs a .net Code 2.2 solution have a nuget restore task. it's trying to connect to our internal feeds. Then it fail. In the build logs we have :
error : Unable to load the service index for source http://internalSource/index.json. [D:\dummy.csproj]
error : No credentials are available in the security package [D:\dummy.csproj]
Looking at TFS generated files, it's not using the credential we declare in our solution.
Our nuget.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageRestore>
<!-- Allow NuGet to download missing packages -->
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
<packageSources>
<clear />
<add key="PackageSTN" value="http://internal/index.json" />
</packageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
<packageSourceCredentials>
<PackageSTN>
<add key="Username" value="user" />
<add key="Password" value="pwd" />
</PackageSTN>
</packageSourceCredentials>
</configuration>
The one on TFS the build give us:
<configuration>
<packageRestore>
<add key="enabled" value="True"/>
<add key="automatic" value="True"/>
</packageRestore>
<packageSources>
<clear/>
<add key="PackageSTN" value="http://internal/index.json"/></packageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)"/>
</activePackageSource>
<packageSourceCredentials>
<PackageSTN>
<add key="Username" value="VssSessionToken"/>
<add key="ClearTextPassword" value="Too Big to be display"/>
</PackageSTN>
</packageSourceCredentials>
</configuration>
Seem like it's trying to use some VssSessionToken TFS account to log on.
In addition we replace the %APPDATA% nuget.config on the server with the one with our credential, in case it will have a look inside, no luck as well.
TFS build .net Core with nuget restore end in error
As we know, when we select the option Feeds in my NuGet.config, we also need provide the Credentials for feeds outside this account/collection:
If we use the token we got from CredentialProvider.VSS.exe in the field "Personal Access Token" in the NuGet connection window, we may got the issue like you. The token we got from CredentialProvider.VSS.exe is a short-lived token, you could replace it with PAT (Personal Access Token) to check if it work for you.
Check this thread for some more details.
Besides, if you are using the old nuget.exe, you can use the task NuGet Tool Installer to update it.
If above not help you, please share your build definition about nuget restore task and the steps how to add the Credentials for feeds outside this account/collection.
Hope this helps.
Finally we did a powershell script, to by-pass this :/
try
{
$solutionSln = $env:BUILD_SOURCESDIRECTORY + $env:solutionSln
$nugetConfig = $env:BUILD_SOURCESDIRECTORY + $env:nugetConfig
Write-Host "dotnet restore $solutionSln --configfile $nugetConfig --verbosity Detailed --no-cache"
dotnet restore $solutionSln --configfile $nugetConfig --verbosity Detailed --no-cache
}
catch {
Write-Host $_
exit 1
}

CruiseControl.net, send dynamic values to some files

I have been searching for a few days, I have also asked a question on the cc.net forum, but still don't have the answer.
My task is to fill Web.config with specific values during the building using cc.net. Here is the example:
I'm developing an ASP.NET website, I have a Web.config with some configuration, e.g. connection string:
<add name="ContextName" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=DatabaseName;User Id = UserName;Password=UserPassword;" providerName="System.Data.SqlClient" />
After the building I want to replace some values and make the config look like this:
<add name="ContextName" connectionString="Data Source=%SERVER%;Initial Catalog=%DATABASE%;User Id = %USER%;Password=%PASSWORD%;" providerName="System.Data.SqlClient" />
I tried this solution, but it didn't help me (or maybe I didn't understand how to use it properly).
Please help me to solve the task.
Thanks!
You can try to use this Config Transformation Tool which is XDT transformation command tool based on XDT (web.config) transform engine, which allows you to run XDT transformation on any XML files. You can use ccnet's task block to run it after your msbuild
<tasks>
<exec>
</exec>
</tasks>
More on ccnet executable task see here.
For more information on XDT transformation see this link in MSDN library
You can create a target on your build file to update the web.config and call that target after the build. I use something similar in my build files, here is an example:
<target name="update-config" >
<property name="export.config" value="" unless="${property::exists('export.config')}" />
<call target="${config-settings}" /> <!-- test or stage -->
<xmlpoke file="${export.config}" xpath="/configuration/appSettings/add[#key='ContextName']/#connectionString" value="${configValue.connectionString}" failonerror="true" />
</target>
<target name="test">
<property name="configValue.connectionString" value="test connection string here" />
</target>
<target name="stage">
<property name="configValue.connectionString" value="stage connection string here" />
</target>
After executing the target that compile your code and export you can run the target update-config, in this case I'm expecting a variable export.config with the path of the exported web.config then calling another target that sets the the value of the connectionstring variable (this can be target test or stage) and finally xmlpoke the web.config with the value.
Hope this helps!

Authentication issue when debugging in VS2013 - iis express

I'm trying to pick up the windows username when debugging in Visual Studio 2013. I am simply using:
httpcontext.current.user.identity.name
If I run this on my Dev Server it works fine, if I run it in debug mode on any previous version of Visual Studio it also works fine.
My problems is - If i run this on visual studio 2013 I get an empty string.
My web config is as follows.
<system.web>
<authentication mode="Windows"/>
<identity impersonate="false"/>
<authorization>
<allow users="*"/>
</authorization>
<compilation debug="true" strict="false" explicit="true" targetFramework="4.0"/>
<customErrors mode="Off"/>
</system.web>
I had just upgraded to VS 2013 from VS 2012 and the current user identity (HttpContext.User.Identity) was coming through as anonymous.
I tried changing the IIS express applicationhost.config, no difference.
The solution was to look at the properties of the web project, hit F4 to get the project properties when you have the top level of the project selected. Do not right click on the project and select properties, this is something entirely different.
Change Anonymous Authentication to be Disabled and Windows Authentication to be Enabled.
Works like gravy :)
As I was researching this I found my answer, but can't find the answer on the internet, so I thought I'd share this:
I fixed my issue by modifying my applicationhost.config file. My file was saved in the "\My Documents\IISExpress\config" folder.
It seems that VS2013 was ignoring my web.config file and applying different authentication methods.
I had to modify this portion of the file to look like the below. In truth, I only modified the anonymousAuthentication to be false and the windowsAuthentication mode to true.
<authentication>
<anonymousAuthentication enabled="false" userName="" />
<basicAuthentication enabled="false" />
<clientCertificateMappingAuthentication enabled="false" />
<digestAuthentication enabled="false" />
<iisClientCertificateMappingAuthentication enabled="false">
</iisClientCertificateMappingAuthentication>
<windowsAuthentication enabled="true">
<providers>
<add value="Negotiate" />
<add value="NTLM" />
</providers>
</windowsAuthentication>
</authentication>
In Visual Studio 2013 AND VS15 (but i guess if the same for all other version) just press F4 and change this two properties:
-Anonymous Authentication: Disable
-Windows Authentication: Enable
In VS2013 F4 on your project to view properties window and disable Anonymous access and enable "Windows authentication"
Then it will work. No need to change anything else
VS 2015 changes this. It added a .vs folder to my web project and the applicationhost.config was in there. I made the changes suggested (window authentication = true, anon=false) and it started delivering a username instead of a blank.
Open up the applicationHost.config file located in the C:\Users[userid]\Documents\IISExpress\config folder. Inside this file change the overrideModeDefault of anonymousAthentication and windowsAuthentication to "Allow"
<sectionGroup name="security">
<section name="access" overrideModeDefault="Deny" />
<section name="applicationDependencies" overrideModeDefault="Deny" />
<sectionGroup name="authentication">
<section name="anonymousAuthentication" overrideModeDefault="Allow" />
<section name="basicAuthentication" overrideModeDefault="Deny" />
<section name="clientCertificateMappingAuthentication" overrideModeDefault="Deny" />
<section name="digestAuthentication" overrideModeDefault="Deny" />
<section name="iisClientCertificateMappingAuthentication" overrideModeDefault="Deny" />
<section name="windowsAuthentication" overrideModeDefault="Allow" />
</sectionGroup>
Next change lockItem to be "false" for AnonymousAuthenticationModule and WindowsAuthenticationModule
<system.webServer>
<modules>
<!--
<add name="HttpCacheModule" lockItem="true" />
-->
<add name="DynamicCompressionModule" lockItem="true" />
<add name="StaticCompressionModule" lockItem="true" />
<add name="DefaultDocumentModule" lockItem="true" />
<add name="DirectoryListingModule" lockItem="true" />
<add name="IsapiFilterModule" lockItem="true" />
<add name="ProtocolSupportModule" lockItem="true" />
<add name="HttpRedirectionModule" lockItem="true" />
<add name="ServerSideIncludeModule" lockItem="true" />
<add name="StaticFileModule" lockItem="true" />
<add name="AnonymousAuthenticationModule" lockItem="false" />
<add name="CertificateMappingAuthenticationModule" lockItem="true" />
<add name="UrlAuthorizationModule" lockItem="true" />
<add name="BasicAuthenticationModule" lockItem="true" />
<add name="WindowsAuthenticationModule" lockItem="false" />
Making these changes will allow the existing web config settings to override what is in the applicationHost file for IIS Express.
You could also modify the project properties for your web project, choose "Web" from left tabs, then change the Servers drop down to "Local IIS". Create a new virtual directory and use IIS manager to setup your site/app pool as desired.
I prefer this method, as you would typically have a local IIS v-directory (or site) to test locally. You won't affect any other sites this way either.
It appears that the right answer is provided by user3149240 above. However, As Neil Watson pointed out, the applicationhost.config file is at play here.
The changes can actually be made in the VS Property pane or in the file albeit in a different spot. Near the bottom of the applicationhost.config file is a set of location elements. Each app for IIS Express seems to have one of these. Changing the settings in the UI updates this section of the file. So, you can either change the settings through the UI or modify this file.
Here is an example with anonymous auth off and Windows auth on:
<location path="MyApp">
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" />
<anonymousAuthentication enabled="false" />
</authentication>
</security>
</system.webServer>
</location>
This is equivalent in the VS UI to:
Anonymous Authentication: Disabled
Windows Authentication: Enabled
F4 doesn't always bring me to this panel. Besides, it is often said that a picture is worth a thousand words.

Moles creation does not create all objects

While trying to create a mole for some unit tests I noticed that some functions were not being 'moled'. Some functions were appearing in the xxx.moles.xml file while others were not.
To resolve this issue, I've tried reinstalling 'Pex and Moles', deleted files in the MolesAssembly folder, restarted the computer, etc.
Finally, I simply opened a console window and ran the moles.exe command from the command prompt.
"c:\program files\microsoft moles\bin\moles.exe" assembly.dll /op:"MolesAssemblies" /msbuild:"c:\windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
The first time I ran this, I received a message:
Moles : info : compilation : assembly metadata hash unchanged,
skipping code generation.
After deleting the moles in the MolesAssemblies folder, I ran the moles.exe command again and all my functions are now appearing in the xxx.moles.dll and xxx.moles.xml files.
Does anyone know why the mole generation does not work when building inside Visual Studio 2010, but it works perfectly from the command prompt?
I found the issue...I modified the .moles file before and only certain classes were added. I simply had to add more 'TypeName' and the classes/functions were included.
The reason that it 'worked' by using the moles.exe command was because I did not use the .moles file (I simply referenced the assembly). I changed the parameters for moles.exe to include the .moles file and the assembly and the results were identical to the output generated by Visual Studio. Once I notice that other parts of the code was breaking, I realized that the .moles file was incorrect.
I had something like this...
<Moles xmlns="http://schemas.microsoft.com/moles/2010/" >
<Assembly Name="Assembly.name" />
<StubGeneration>
<Types>
<Clear />
<Add FullName="Fullname_1_0" />
</Types>
</StubGeneration>
<MoleGeneration>
<Types>
<Clear />
<Add FullName ="Fullname_1_0" />
</Types>
</MoleGeneration>
</Moles>
I needed a second 'Add'
<Moles xmlns="http://schemas.microsoft.com/moles/2010/" >
<Assembly Name="Assembly.name" />
<StubGeneration>
<Types>
<Clear />
<Add FullName="Fullname_1_0" />
</Types>
</StubGeneration>
<MoleGeneration>
<Types>
<Clear />
<Add FullName ="Fullname_1_0" />
<Add TypeName="AdditionalClass"/>
</Types>
</MoleGeneration>
</Moles>
Be sure to REBUILD the test project, after modifying an assembly that is moled. Using the "clean" action on the test project will also fix this issue.