Persisting app.config variables in updates via Click once deployment - deployment

Every time a new update is released for an application with click once, the variables in the app.config file are destroyed
<userSettings>
<app.My.MySettings>
<setting name="Email" serializeAs="String">
<value />
</setting>
<setting name="UserName" serializeAs="String">
<value />
</setting>
</app.My.MySettings>
</userSettings>
How can i prevent that?
Is there any way of feching the variables from the previous application version?

Do you have the "Applications should check for updates" option checked?
Have a look at Exploring Secrets of Persistent Application Settings (the section titled "Maintaining Settings Between Program Versions"):
For any settings from the current
version that match settings in the
prior version, this routine will
import them into the current version's
user.config file:
At the entry point to your program, place the following code.
if (Properties.Settings.Default.UpgradeSettings)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UpgradeSettings = false;
}
Note that UpgradeSettings is a boolean user setting (not application) that you need to add yourself, and you want the default value to be True.

If you use user-level settings instead of application-level settings, it will copy them forward when a new version is retrieved.
The safest thing to do, though, is to separate this data from the ClickOnce update, uh, "experience". See if this helps:
http://robindotnet.wordpress.com/2009/08/19/where-do-i-put-my-data-to-keep-it-safe-from-clickonce-updates/

Related

Continue the Wix setup after having a service that could not start

We have a setup in which we have a service that we try to install and run.
For some reason, the service cannot start(due to a port already in use). This isn't critical for us and should not stop the setup.
The service is declared like this:
<DirectoryRef Id="BIN">
<Component Id="MyService" Guid="*" SharedDllRefCount="yes">
<File Id="MyService.exe" Name="MyService.exe" KeyPath="yes" Vital="no" Compressed="default" DiskId="1" Source="$(var.DirDotfuscated)\MyService.exe" />
<ServiceControl Id="Install" Name="MyService" Start="install" Stop="install" />
<ServiceControl Id="Uninstall" Name="MyService" Stop="uninstall" Remove="uninstall" />
<ServiceInstall Id="NewServiceInstall2" Name="MyService" DisplayName="My Service" Type="ownProcess" Interactive="no" Start="auto" ErrorControl="normal" Description="My service" Vital="no" />
</Component>
<Component Id="Xms_HostService_Files" Guid="*" SharedDllRefCount="yes">
<File Id="MyService.exe.config" Name="MyService.exe.config" Vital="no" Compressed="default" DiskId="1" Source="$(var.DirDotfuscated)\MyService.exe.config" />
<File Id="MyServiceCommon.dll" Name="MyServiceCommon.dll" Vital="no" Compressed="default" DiskId="1" Source="$(var.DirDotfuscated)\MyServiceCommon.dll" />
<File KeyPath="yes" Id="MyServiceCore.dll" Name="MyServiceCore.dll" Vital="no" Compressed="default" DiskId="1" Source="$(var.DirDotfuscated)\MyServiceCore.dll" />
</Component>
</DirectoryRef>
When we execute the setup, we get this error:
And then, we only have the option to Retry(which will also fail) or cancel(that stops the setup).
We tried so many things(only put serviceInstall, not serviceControl, ...) but at some point we always have an error.
How should we manage this?
Attempted Answer (without ability to test):
What happens if you set the ServiceControl element's Wait attribute to "no"? I don't have a service exe to test with at the moment, but I believe that could work as you intend it.
Custom actions should generally be avoided for reliability reasons, but on the other hand - if you do need something special - that's what they are there for. Be prepared for most deployment problems to originate from your custom actions though: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
Some further advice (which was not asked for :-) ):
You should not install multiple binaries with one component. You should use one file per component for many reasons. Windows Installer best practice specifically dictates to have only one binary per component, but in my opinion you should use one component per file in general to make minor upgrades and patching possible, and self-repair more reliable.
To better understand component reference counting: Change my component GUID in wix?
By eliminating hard-coded GUIDs you can take advantage of WiX's advanced auto-GUID creation concept. This will change the component GUID if the absolute installation path changes. This is correct behavior for component reference counting. Auto-magic. You either set Guid="*" or just leave out the Guid attribute entirely. A few installation locations need a hard coded GUID - the WiX compiler will warn you and explain why.
If you do change the component structure (to use one file per component) you should change the installation path to "break the link to past sins" with regards to component reference counting. This is a very complex topic to explain, but changing the installation path will sort all problems for you - if you also enable the auto component GUIDs I mentioned in the previous point. Keep the path stable from then on (until you have a major new version).
You can do it as simple as adding a sub folder with the the application's major (and minor?) version to the main installation folder hierarchy: "Program Files\MyCompany\MySoftware\5" instead of "Program Files\MyCompany\MySoftware".
I would only add the major version to the path and keep the installation path stable throughout your application's lifetime and then increment when you want to break the link to previous installers for a major new software version (for example if you want to install two versions side-by-side - your application must be built to handle this properly, i.e not overwriting shared settings in the registry from both versions etc...).
You might want to consider simplifying your WiX source file by only specifying values for attributes that are non-standard (otherwise rely on defaults). This can substantially simplify your WiX source files. Here is an example: Syntax for guids in WIX?
Just a quick sample inline (same as in link above - check it out), this is all that is required to install a normal file with default attributes / parameters - all other attributes default well - unless you want to override something:
<Component>
<File Source="..\File.dll" />
</Component>
Some links:
Windows Installer Best Practices (full list).
Windows Installer Best Practices - Organizing Applications into Components (specifically for component creation).
When component reference counting has gone haywire (missing files after upgrades, unexpected removal of shared files on uninstall, etc...): WiX 3.8: Two MSI using the same registry values. How to delete registry values only if both MSI are uninstalled?
Drop the ServiceControl element in lieu of a CustomAction element with #DllEntry="WixQuietExec" set, then use a standard means of starting the service like net start foo and ignore the result. See Quiet Execution Custom Action for details.

How do I prevent Ebuild from updating my project dependences

Whenever I run workspace.xml it updates the revisions stated in my project's module.revisions file. How can I stop this?
You need to set the EBuild property update-upstream to false.
To do this, edit workspace.xml and find it, making it look like the following:
<property name="update-upstream" value="false"/>

AjaxControlToolkit 7.0123 breaks VS2012 Web Application Project

I have an existing VS2012 web application that has been running fine until I added in the latest AjaxControlToolkit (7.0123). Initially, I found that the installation broke the behaviour of the UpdatePanel - whereas before I could refresh a page after an asynchronous post-back without repeating the operation I found that after installation the refresh would repeat the previous operation (I guess the post-back was no longer asynchronous).
I then noticed that, at some time in the past, I had commented out a number of the default JavaScript files that are added to a new ASP.NET Web Forms Application so I tried adding them back in. This resulted in an exception:
'MsAjaxBundle' is not a valid script name. The name must end in
'.js'.
I then tried replacing the default <asp:ScriptManager .../> with <ajaxControlToolkit:ToolkitScriptManager .../> this resulted in a new exception
Could not load file or assembly 'System.Web' or one of its
dependencies. The system cannot find the file specified.
For sanity, I then created a fresh ASP.NET Web Forms Application (VS2012, Update 2) and ran it. No errors. Using "nuget", I then added the AjaxControlToolkit v7.0123 (the latest release). Ran the application again and I get the original exception again:
'MsAjaxBundle' is not a valid script name. The name must end in
'.js'.
Once again, I replaced <asp:ScriptManager .../> with <ajaxControlToolkit:ToolkitScriptManager .../> and once again this results in
Could not load file or assembly 'System.Web' or one of its
dependencies. The system cannot find the file specified.
Can anybody shed any light on what else I need to do to resolve this? I can find no documentation to say anything needs to be changed manually when adding the toolkit.
Thanks,
Answer found at http://stephenwalther.com/archive/2012/09/20/september-2012-release-of-the-ajax-control-toolkit.aspx (always just after posting the question huh)
Replacing <asp:ScriptManager .../> with <ajaxControlToolkit:ToolkitScriptManager .../> is correct
Need to remove reference to MsAjaxBundle
Need to remove Assembly="System.Web" from script references
This fixes the exceptions (both in the new project and the original).
It does not however resolve the problem with the UpdatePanel no longer posting back asynchronously. I will raise this as a new question.
If you are using the April 2013 Release of the Ajax Control Toolkit see Stephen Walther's latest blog post:
http://stephenwalther.com/archive/2013/04/30/april-2013-release-of-the-ajax-control-toolkit.aspx
I was missing the new web.config settings that allow the AjaxFileUpload control to work in the new release
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" maxRequestLength="42949672" />
<httpHandlers>
<add verb="*" path="AjaxFileUploadHandler.axd" type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit"/>
</httpHandlers>
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<handlers>
<add name="AjaxFileUploadHandler" verb="*" path="AjaxFileUploadHandler.axd" type="AjaxControlToolkit.AjaxFileUploadHandler, AjaxControlToolkit"/>
</handlers>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="4294967295"/>
</requestFiltering>
</security>
</system.webServer>
</configuration>
When you see this "'MsAjaxBundle' is not a valid script name. The name must end in '.js'."
The Best thing you can do is:
Go to the site Master (Double click on it )
Search for "MsAjaxBundle" or " "
Comment this line eg. <%----%>
Save or compile your program and then run it
Thank God is working by now

Expected behaviour in Sitecore for config include files with patch:delete

I am working on moving the custom configuration settings for a Sitecore (6.2) project into a separate App_Config\Include file. I am testing my changes using the sitecore page /sitecore/admin/ShowConfig.aspx. My question is what is the expected behaviour when using the <patch:delete /> element?
In my include file I have the following:
<setting name="Preview.DefaultSite">
<patch:delete/>
</setting>
When I look at ShowConfig.aspx I see the following:
<setting name="Preview.DefaultSite" value="website">
<delete/>
</setting>
Is this correct and expected behaviour, or should the <setting name="Preview.DefaultSite"> element completely disappear?
The element should completely disappear and this works as expected for me in Sitecore 6.5 (update-5) and I know it worked in 6.4 as well.
Which version of Sitecore are you using?
All the patch attributes are mentioned here: All About web.config Include Files with the Sitecore ASP.NET CMS but the comments suggest some people had issues with this. This article from 2010 on web.config includes also mentions you cannot delete but like I said, it works in the newer versions.
You could always patch the attribute to remove the value:
<setting name="Preview.DefaultSite">
<patch:attribute name="value"></patch:attribute>
</setting>

TFS2010 Build Definition to Deploy to multiple servers?

I've been looking into TFS2010 new build and deployment features with MSDeploy. So far everything is going well (although its been hard to find information about specific scenarios).
Can I modify my Build Definition to specify 2 or more servers to deploy to? What I need to do is deploy to multiple servers (as I have two in my testing environment which uses a NLB).
What I have now is a Build definition which Builds, runs my tests, and then Deploys to ONE of my testing servers (which has the MsDeployAgentService running on it). It works fine, and each web project is deployed as configured in its project file. The MSBuild Arguments I use are:
* /p:DeployOnBuild=True
* /p:DeployTarget=MsDeployPublish
* /p:MSDeployServiceURL=http://oawww.testserver1.com.au/MsDeployAgentService
* /p:CreatePackageOnPublish=True
* /p:MsDeployPublishMethod=RemoteAgent
* /p:AllowUntrustedCertificated=True
* /p:UserName=myusername
* /p:Password=mypassword
NB: I dont use /p:DeployIISAppPath="xyz" as it doesnt deploy all my projects and overrides my project config.
Can I add another build argument to get it to call more than one MSDeployServiceURL? Like something like a second /p:MSDeployServiceURL argument that specifies another server?
Or do I have to look for another solution, such as editing the WF?
I saw an almost exact same question here posted 2 months ago: TFS 2010 - Deploy to Multiple Servers After Build , so it doesn't look like I'm the only one trying to solve this.
I also posted on the IIS.NET forums where MSDeploy is discussed: http://forums.iis.net/t/1170741.aspx . It's had quite a lot of views, but again, no answers.
You don't have to build the project twice to deploy to two servers. The build process will build a set of deployment files. You can then use the InvokeProcess to deploy to multiple servers.
First create a variable named ProjectName. Then add an Assign activity to the "Compile the Project" sequence. This is located in the "Try to Compile the Project" sequence. Here are the properties of the Assign:
To: ProjectName
Value: System.IO.Path.GetFileNameWithoutExtension(localProject)
Here are the properties of our InvokeProcess activity that deploys to the test server:
Arguments: "/y /M:<server> /u:<domain>\<user> /p:<password>"
FileName: String.Format("{0}\{1}.deploy.cmd", BuildDetail.DropLocation, ProjectName)
You will need to change <server>, <domain>, <user>, and <password> to the values that reflect your environment.
If you need to manually deploy to a server you can run the command below from your build folder:
deploy.cmd /y /M:<server> /u:<domain>\<user> /p:<password>
I couldn't find the solution I was looking for, but here's what I came up with in the end.
I wanted to keep the solution simple and configurable within the TFS arguments while at the same time staying in line with the already provided MSBuildArguments method which has been promoted a lot. So I created a new Build Template, and added a new TFS WorkFlow Argument called MSBuildArguments2 in the Arguments tab of the WorkFlow.
I searched through the BuildTemplate WorkFlow for all occurances of the MSBuildArguments (there were two occurances).
The two tasks that use MSBuildArguments are called Run MSBuild for Project. Directly below this task, I added a new "If" block with the condition:
Not String.IsNullOrEmpty(MSBuildArguments2)
I then copied the "Run MSBuild for Project" task and pasted it into the new If's "Then" block, updating its title accordingly. You'll also need to update the new Task's ConmmandLineArguments property to use your new Argument.
CommandLineArguments = String.Format("/p:SkipInvalidConfigurations=true {0}", MSBuildArguments2)
After these modifications, the WorkFlow looks like this:
Save and Check In the new WorkFlow. Update your Build Definition to use this new WorkFlow, then in the build definition's Process tab you will find a new section called Misc with the new argument ready to be used. Because I'm simply using this new argument for deployment, I copied the exact same arguments I used for MSBuild Arguments and updated the MSDeployServiceURL to my second deployment server.
And that's that. I suppose a more elegant method would be to convert MSBuildArguments into an array of strings and then loop through them during the WorkFlow process. But this suits our 2 server requirements.
Hope this helps!
My solution to this is a new Target that runs after Package. Each project that needs to produce a package includes this targets file, and I chose to make the Include conditional on an externally-set "DoDeployment" property. Additionally each project defines the DeploymentServerGroup property so that the destination server(s) are properly filtered depending on what kind of project it is.
As you can see towards the bottom I'm simply executing the command file with the server list, pretty simple.
<!--
This targets file allows a project to deploy its package
As it is used by all project typesconditionally included from the project file
-->
<UsingTask TaskName="Microsoft.TeamFoundation.Build.Tasks.BuildStep" AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.ProcessComponents.dll" />
<!-- Each Server needs the Group metadatum, either Webservers, Appservers, or Batch. -->
<Choose>
<When Condition="'$(Configuration)' == 'DEV'">
<ItemGroup>
<Servers Include="DevWebServer">
<Group>Webservers</Group>
</Servers>
<Servers Include="DevAppServer">
<Group>Appservers</Group>
</Servers>
</ItemGroup>
</When>
<When Condition="'$(Configuration)' == 'QA'">
<ItemGroup>
<Servers Include="QAWebServer1">
<Group>Webservers</Group>
</Servers>
<Servers Include="QAWebServer2">
<Group>Webservers</Group>
</Servers>
<Servers Include="QAAppServer1">
<Group>Appservers</Group>
</Servers>
<Servers Include="QAAppServer2">
<Group>Appservers</Group>
</Servers>
</ItemGroup>
</When>
</Choose>
<!-- DoDeploy can be set in the build defintion -->
<Target Name="StartDeployment" AfterTargets="Package">
<PropertyGroup>
<!-- The _PublishedWebsites area -->
<PackageLocation>$(WebProjectOutputDir)_Package</PackageLocation>
<!-- Override for local testing -->
<PackageLocation Condition="$(WebProjectOutputDirInsideProject)">$(IntermediateOutputPath)Package\</PackageLocation>
</PropertyGroup>
<Message Text="Tier servers are #(Servers)" />
<!-- A filtered list of the servers. DeploymentServerGroup is defined in each project that does deployment -->
<ItemGroup>
<DestinationServers Include="#(Servers)" Condition="'%(Servers.Group)' == '$(DeploymentServerGroup)'" />
</ItemGroup>
<Message Text="Dest servers are #(DestinationServers)" />
</Target>
<!-- Only perform the deployment if any servers fit the filters -->
<Target Name="PerformDeployment" AfterTargets="StartDeployment" Condition="'#(DestinationServers)' != ''">
<Message Text="Deploying $(AssemblyName) to #(DestinationServers)" />
<!-- Fancy build steps so that they better appear in the build explorer -->
<BuildStep
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
Message="Deploying $(AssemblyName) to #(DestinationServers)...">
<Output TaskParameter="Id" PropertyName="StepId" />
</BuildStep>
<!-- The deployment command will be run for each item in the DestinationServers collection. -->
<Exec Command="$(AssemblyName).deploy.cmd /Y /M:%(DestinationServers.Identity)" WorkingDirectory="$(PackageLocation)" />
<BuildStep
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
Id="$(StepId)"
Status="Succeeded"
Message="Deployed $(AssemblyName) to #(DestinationServers)"/>
<OnError ExecuteTargets="MarkDeployStepAsFailed" />
</Target>
<Target Name="MarkDeployStepAsFailed">
<BuildStep
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
Id="$(StepId)"
Status="Failed" />
</Target>
I am the author of the other similar post. I have yet to find a solution. I believe it is going to be modifying the workflow to add a postprocessing MSBUILD -sync task. That seems to be the most elegant, but was still hoping to find something a bit less intrusive.
I'm not sure if that could help you with TFS 2010, but I have a blog post for TFS 2012: Multiple web projects deployment from TFS 2012 to NLB enabled environment.