The Settings section with name 'Blah' in ConfigOverride 'Config' is invalid. Cannot find a section with the same name - azure-service-fabric

I'm trying to add a new config section to our SF app configuration and it is failing:
Register-ServiceFabricApplicationType : The Settings section with name 'Blah' in ConfigOverride
'Config' is invalid. Cannot find a section with the same name.
Nothing fancy, done this many times before but I'm doing something wrong and I don't see.
<ApplicationManifest xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="eBenefits.OrganizationDomainType" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="Parameter1" DefaultValue="" />
<Parameter Name="Parameter2" DefaultValue="" />
<Parameter Name="Parameter3" DefaultValue="" />
</Parameters>
<ConfigOverrides>
<ConfigOverride Name="Config">
<Settings>
...
<Section Name="Blah">
<Parameter Name="Parameter1" Value="[Parameter1]" />
<Parameter Name="Parameter2" Value="[Parameter1]" />
<Parameter Name="Parameter3" Value="[Parameter1]" />
</Section>
</Settings>
</ConfigOverride>
</ConfigOverrides>
...
</ApplicationManifest>
Copying application to image store...
Upload to Image Store succeeded
Registering application type...
Register-ServiceFabricApplicationType : The Settings section with name 'Blah' in ConfigOverride
'Config' is invalid. Cannot find a section with the same name.
FileName: C:\SfDevCluster\Data\ImageBuilderProxy\AppType\a2b68765-272d-4477-aad2-f3d4818365c7\ApplicationManifest.xml
At C:\Program Files\Microsoft SDKs\Service
Fabric\Tools\PSModule\ServiceFabricSDK\Publish-NewServiceFabricApplication.ps1:251 char:9
+ Register-ServiceFabricApplicationType -ApplicationPathInImage ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Microsoft.Servi...usterConnection:ClusterConnection) [Register-Servic
eFabricApplicationType], FabricException
+ FullyQualifiedErrorId : RegisterApplicationTypeErrorId,Microsoft.ServiceFabric.Powershell.RegisterApplicationTyp
e
Finished executing script 'Deploy-FabricApplication.ps1'.
Time elapsed: 00:00:39.7598137
The PowerShell script failed to execute.

I forgot to define it in My-Service\PackageRoot\Config\Settings.xml
Reference: Full instructions on adding SF settings

For anyone else who encountered this issue and already have Settings.xml files, you may wish to create a new Settings.xml using the Visual Studio context menu (new xml file) and get rid of the previous one after copying its contents across. For whatever reason Visual Studio did not recognise that I had a Settings.xml file and thus SF was unable to access it.
After doing this everything works.

Related

Azure Devops Release XML variables not being replaced

I'm trying to create a release where variables from my library are used to replace values in SetParameters.xml. For replacing I used following task: https://github.com/qetza/vsts-replacetokens-task#readme
In my web.config I have following for my connectionStrings:
<connectionStrings configSource="config\connectionStrings.local.config" />
For deployment, this should use another file, eg:
<connectionStrings configSource="config\connectionStrings.config" />
My parameters.xml looks like this:
<parameter name="Connection Strings Config File Location"
defaultValue="__ConnectionStringsConfigurationFileLocation__">
<parameterEntry kind="XmlFile"
scope="\\Web.config$"
match="/configuration/connectionStrings/#configSource" />
<parameter name="Umbraco Database Connection String"
defaultValue="__UmbracoDatabaseConnectionString__">
<parameterValidation kind="AllowEmpty" />
<parameterEntry kind="XmlFile"
scope="\\config\\connectionStrings.config$"
match="/connectionStrings/add[#name='umbracoDbDSN']/#connectionString" />
The variable ConnectionStringsConfigurationFileLocation is in my library:
After deploying, the value of the configSource in web.config remains untouched. But the value of connectionString in \config\connectionStrings.config is replaced succesfully.
What could be the issue that the web.config is not updating?
Edit: Screenshots tasks:
replace
deploy

Controlling the sequence of events in a Wixtoolset (.msi) installer

I am creating a Microsoft Installer (.msi file) using the Wixtoolset (Windows Installer XML). This installer must automate the installation of an existing .exe program (named installer.exe below) and copy a custom configuration file (named settings.conf below) to the target directory. In addition the installer must modify the configuration file using the InstallFiles command below. But the timing of events is critical. If the executable installer runs too early, it fails or exhibits strange behavior. And if the executable installer run too late in the install sequence, it overwrites my modified configuration file with the generic values. I believe this can be done by assigning a string to the Before or After property value. What Before or After property assignment will allow the executable to run properly but not overwrite the configuration file I moved by the CopyFile element? Here is my Wixtoolset XML code.
<Property Id="CONFIGFOLDER" Value="C:\acme\config" >
<Feature
Id="ConfigurationFile"
Title="Configuration File"
Level="1"
<ComponentRef Id="CMP_ACME_Config_File" />
</Feature>
<DirectoryRef Id="TARGETDIR">
<Component Id="CMP_ACME_Config_File" Guid="">
<File
Id="ACME_Config"
Source="MySettings.conf"
KeyPath="yes"
<CopyFile Id="Copy_ACME_Config"
DestinationProperty="CONFIGFOLDER"
DestinationName="settings.conf" />
</File>
</Component>
</DirectoryRef>
<Binary
Id="InstallerEXE"
SourceFile="installer.exe" />
<CustomAction
Id="Launch_Installer"
BinaryKey="InstallerEXE"
Impersonate="yes"
Execute="deferred"
ExeCommand=""
Return="check" />
<InstallExecuteSequence>
<Custom Action="Launch_Installer"
Before="InstallFiles">
</Custom>
</InstallExecuteSequence>
</Property>
I can't explain exactly why this works but assigning "InstallFiles" to the "After" property in the "Custom" element seems to do the trick.
<InstallExecuteSequence>
<Custom Action="Launch_Installer"
After="InstallFiles">
</Custom>
</InstallExecuteSequence>

WiX Bootstrapper: How do I set burn variables from the command line?

Using WiX 3.7 and .NET 4.0.
How does one set burn variables when running a WiX bootstrapper EXE from the command line?
First of all, the burn variables that you wish to set need to be set as Overridable. To do this you must include the follow namespace in your WXS: xmlns:bal="http://schemas.microsoft.com/wix/BalExtension" and if you're using Visual Studio like me you need to include WixBalExtension.dll in your project references. Next you need to add the following attribute to all of the burn variables that you want to set via the command line: bal:Overridable="yes".
Now you can set the variables via the command line in this fashion:
BootstrapperSetup.exe /i /passive MyBurnVariable1=1 MyBurnVariable2=2
Below is an example of a WXS file that satifies all of the conditions described above:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="MyProduct" Version="1.0.0" Manufacturer="MyManufacturer" UpgradeCode="PUT-UPGRADE-CODE-HERE">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense">
<bal:WixStandardBootstrapperApplication LicenseUrl="MyLicense.htm" ThemeFile="MyThemeFile.xml" LocalizationFile="MyLocFile.wxl" />
</BootstrapperApplicationRef>
<Variable Name="MyBurnVariable1" bal:Overridable="yes" Type="numeric" Value="0" />
<Variable Name="MyBurnVariable2" bal:Overridable="yes" Type="numeric" Value="0" />
<Chain>
<MsiPackage Id="MyFirstMsiPackage"
SourceFile="first.msi"
InstallCondition="MyBurnVariable1 = 1" />
<MsiPackage Id="MySecondMsiPackage"
SourceFile="second.msi">
<MsiProperty Name="MY_PROPERTY" Value="[MyBurnVariable2]" />
</MsiPackage>
</Chain>
</Bundle>
</Wix>

MSDeploy setParamFile is not recognizing parameters

I'm trying to use MSDeploy with the parameter settings file option so I can build once and deploy to multiple environments by overriding the parameters with different files. From PowerShell I'm calling msdeploy.
msdeploy.exe -verb:sync `
-source:"contentPath='$SourceLocalPath'" `
-dest:"contentPath='$TargetLocalPath',computername='$TargetServer'"
-setParamFile:"$ParamFilePath" `
-verbose
This results in an error about not recognizing parameters.
msdeploy.exe : Error: The declared parameter 'SqlConnString' is not
recognized.
If I remove the "setParamFile" line, it deploys fine, but then uses default values. Also if I try to manually import the package from IIS, it displays the parameters with defaults filled in.
I have a Parameter.xml file in the root of the web project:
<parameters>
<parameter name="SqlConnString" description="Please provide the SQL connection string" defaultValue="...;Initial Catalog=xxx;server=xxx;" tags="">
<parameterEntry kind="XmlFile" scope="\\web.config$" match="/configuration/connectionStrings/add[#name='Sql']/#connectionString" />
</parameter>
</parameters>
The package is getting created with a ...SetParameters.xml file inside the package, which contains the entries from my Parameters.xml file plus the standard entries.
<parameters>
<setParameter name="SqlConnString" value="...Initial Catalog=xxx;server=xxx;"/>
...
</parameters>
Thank you
Try changing the value in "name" from "SqlConnString" to "YourSqlConnectionName-Web.config Connection String". If you want to know the exact name you have to look at your web.config file. The above example should work for a section like this in your web.config file:
<connectionStrings>
<add name="YourSqlConnectionName"
connectionString="...;Initial Catalog=xxx;server=xxx;"
providerName="System.Data.EntityClient"/>
</connectionStrings>
So you should configure your setParameters.xml file like:
<parameters>
<setParameter name="YourSqlConnectionName-Web.config Connection String" value="...Initial Catalog=xxx;server=xxx;"/>
</parameters>
and your Parameters.xml file like:
<parameters>
<parameter name="YourSqlConnectionName-Web.config Connection String" description="Please provide the SQL connection string" defaultValue="...;Initial Catalog=xxx;server=xxx;" tags="">
<parameterEntry kind="XmlFile" scope="\\web.config$" match="/configuration/connectionStrings/add[#name='YourSqlConnectionName']/#connectionString" />
</parameter>
</parameters>
Hope this solves your issue.

x64 Word 2010 Add In registration using WiX

I' deploying a Word Add in using WiX, regarding x84 target Platforms (at least the Office installation has to be x86, never the less which OS Platform is used) everything is working well, my COM Interop registration of the Word Add In works and the add in auto-starts the first time I start word afer I installed the Add In.
I'm doing following registration stuff to the registry (cut from output of heat.exe)
I've created an intermediate file, helping me out for the COM Interop registration using this heat command:
"C:\Program Files\Windows Installer XML v3.5\bin\heat.exe" file MyAddin.dll -ag -template fragment -out MyAddin.wxs
The output of interesst looks like: (I know using RegistryValue this way has been deprecated)
<Class Id="{10BC65F1-32C0-3ED4-98A0-17661A8C4455}" Context="InprocServer32" Description="MyAddin.MyAddinClass" ThreadingModel="both" ForeignServer="mscoree.dll">
<ProgId Id="MyAddin.MyAddinClass" Description="MyAddin.MyAddinClass" />
</Class>
<File Id="filCC4172BEC1312562EDEF49648E45AE0D" KeyPath="yes" Source="..\MyAddin\bin\Debug\MyAddin.dll" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}" Value="" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32\1.0.0.0" Name="Class" Value="MyAddin.MyAddinClass" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32\1.0.0.0" Name="Assembly" Value="MyAddin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32\1.0.0.0" Name="RuntimeVersion" Value="v4.0.30319" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32\1.0.0.0" Name="CodeBase" Value="file:///[#filCC4172BEC1312562EDEF49648E45AE0D]" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32" Name="Class" Value="MyAddin.MyAddinClass" Type="string"Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32" Name="Assembly" Value="MyAddin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32" Name="RuntimeVersion" Value="v4.0.30319" Type="string" Action="write" />
<RegistryValue Root="HKCR" Key="CLSID\{10BC65F1-32C0-3ED4-98A0-17661A8C4455}\InprocServer32" Name="CodeBase" Value="file:///[#filCC4172BEC1312562EDEF49648E45AE0D]" Type="string" Action="write" />
The component including this stuff has the Win64Flag tag set to yes. Therefore I thought things will be written to the x64 part of the registry. Until this, i read following article about registry reflection telling this:
For example, the 32-bit InprocServer32 key is not relevant for 64-bit applications, so the InprocServer32 key is not reflected to the 64-bit registry view.
Furthermore:
However, 64-bit applications can use the 32-bit LocalServer32 key and the LocalServer32 key gets reflected.
But I already tried to use LocalServer32 instead of InprocServer32, but doing this, won't let my add in start on both platforms.
Will I have to use a call to RegAsm Tool or I'm missing a some tag or Interop registration option for x64 Platforms? Can anybody help?
With wix you need to do two things to disable registry reflection:
Mark your component as 64 bit component (attribute Win64="yes") (as you did)
Build your package as 64 bit package (Platform = x64)
This package won't be usable on x86 systems. So you will need two packages, one for x86 and one for x64. You can use the same source file for both packages as the Win64 attribute is ignored by the x86 package.