Why can't I change these settings shown in the image below?
This is a clickOnce application, and my problem is that I want to change by publish path, assembly name, product name, install URL, and preform some app.config translations based on the build configuration. I am able to achieve this by manually editing the csproj like so
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<AssemblyName>someApplicationTest</AssemblyName>
<ProductName>Some Application Test</ProductName>
<PublishUrl>c:\publish\someApplicationTest\</PublishUrl>
<InstallUrl>http://sub.example.com/someApplicationTest/</InstallUrl>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
<AssemblyName>someApplication</AssemblyName>
<ProductName>Some Application</ProductName>
<PublishUrl>c:\publish\someApplication\</PublishUrl>
<InstallUrl>http://sub.example.com/someApplication/</InstallUrl>
</PropertyGroup>
I'm just confused why these options are disabled in visual studio and if I'm missing something. Perhaps I'm confused and these controls weren't even intended for this purpose.
Also, I'm going to be investigating Squirrel.Windows as an alternative later, but for now I wanted to learn more about this.
This is just a visual representation of the structure of a project file. Some settings can have different values for different configurations. Others have only one value that doesn't depend on the configuration. The best example of the first set are the settings in the Build tab. Of course you want to build your program differently in the Release build. So the configuration combos are enabled.
Also have a look-see in the .csproj file with a text editor, Notepad will do just fine. Note the <PropertyGroup> elements, some have a Condition attribute that enables them for a specific configuration. The publish properties are located in the PropertyGroup without a Condition.
So for the settings in the Publish tab Microsoft decided that it was not necessary to make the settings specific to a configuration. Which makes sense if you think about it, you'd only publish your Release build. Well, normally. So the combos are disabled. Feature, not a bug.
Related
I figured how to change the filename of the output assembly depending on the current configuration:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
<OutputPath>path-to-debug-output</OutputPath>
<AssemblyName>myAssembly.Debug</AssemblyName>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="Configuration">
<OutputPath>path-to-release-output</OutputPath>
<AssemblyName>myAssembly</AssemblyName>
</PropertyGroup>
Unfortunately, now everytime I hit "build all" in Visual Studio in debug configuration, it actually rebuilds everything even if no changes were done at all:
1> myAssembly -> path-to-debug-output\myAssembly.Debug.dll
In release mode I get this message exactly one time, after that "myAssembly" is not build until I do any changes to the code.
I suppose there is some check for existence of the output assembly done (and maybe timestamp checking etc.). Does someone know how I can configure this in my .csproj file (or somewhere else)?
[EDIT]
Here is an example of a full .csproj file with configuration dependent output files: http://pastebin.com/pFj4nxtj
I have a C# app with a few different build configurations for different 'flavors' of the app. I would like to have ClickOnce publish options for each configuration, rather than have to set them each time I do a build-and-publish. It appears that the publish options apply to all the configurations. Is there a way to make publish options specific to each configuration?
You cannot make them different for each configuration directly inside Visual Studio. You need to edit the .csproj file and make the following changes to the things you need to be different.
E.g. the first <PropertyGroup> element contains the <PublishUrl> element. You can apply conditions and add the element multiple times:
<PublishUrl Condition=" '$(Configuration)' == 'Debug' ">debug\</PublishUrl>
<PublishUrl Condition=" '$(Configuration)' == 'Release' ">release\</PublishUrl>
When the project is published using the Debug configuration, it will be published to the debug directory.
When the project is published using the Release configuration, it will be published to the release directory.
Apply this conditions to the elements you need to modify. Sadly, you can apply the condition to a whole PropertyGroup, but this is much more complex, as you need to duplicate and keep track of both groups, if you make a change in any of them.
BUT:
This will be overwritten every time you save the project from inside Visual Studio.
So you can either make a xslt file which transforms the file before publishing, or directly create your own publishing application, that fills all required publishing parameter only when publishing it e.g. from a build server.
Edit
This answer will not help. Since I wrote it, I found out that even when using the Choose element, the Visual Studio IDE (at least VS2015) can't seem te keep its hands off our configuration. Although the code below works, when switching between configurations and publishing, at some point the IDE will overwrite this section in the project file in such a way that it no longer works as intended.
Because it technically works as is, and as such could perhaps be useful when using another tool for publishing (or when the issue in VS gets fixed), I'll leave the original answer for reference.
Original answer
I too first tried the solution mentioned by Herdo, only to run into the big "But" he mentions; Visual Studio overwriting your conditionals every time you save the project file.
However, I since found that with the Choose element you can achieve the same behavior without Visual Studio messing with it. You still need to manually edit the .csproj file though.
In short, do not apply the Conditional directly to the PublishUrl tag in the first property group. It will get overwritten by Visual Studio. Instead, define another one later in the project file. When building or publishing, the second one's value will supersede the first one's value, but the IDE will leave it alone. It is that second one you can make conditional using a Choose group.
Below that first property group, add section like this:
<Choose>
<When Condition=" '$(Configuration)' == 'Debug' ">
<PropertyGroup>
<PublishUrl>your\debug\publish\location</PublishUrl>
</PropertyGroup>
</When>
<When Condition=" '$(Configuration)' == 'Release' ">
<PropertyGroup>
<PublishUrl>your\release\publish\location</PublishUrl>
</PropertyGroup>
</When>
</Choose>
Of course, you can add as many configurations and flavors as you like.
At the menu where you set Debug, Release. You can create a new type of configuration. Once you created your own configuration. You can use the code above:
#if ReleaseConfiguration1
//specifics configuration 1 goes here
#endif
#if ReleaseConfiguration2
//specifics configuration 2 goes here
#endif
I have a C# project in vs2010 that has several build options (Debug, Release, Debug x86, Debug I Just Got A New Hat, etc), because some people have gone a bit overboard in adding projects.
I want to revert all of that to just the four basic build types:
debug x86
release x86
debug x64
release x64
I remove a project, save the sln with that project apparently no longer in the solution, and then add it back, but apparently the settings for the project have been saved. Is there any way to remove these extraneous projects entirely from the build manager and start from scratch short of creating a new SLN file?
The impetus for fixing this problem is that one of the projects in the solution won't allow for an x64 build to be made. If I try to create an x64 build for that project, the build manager states that the x64 build already exists, even when though clearly does not. The build manager isn't allowing me to remove build modes, just add them, but then it doesn't let me add the x64, which is what I'm needing.
Quickest way is to manually edit the .proj files in notepad, removing all the
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'NewHat|x64' ">...</PropertyGroup>
elements for each configuration. Then finally remove the unwanted solution configurations by again editing the .sln file in notepad. They are easy to spot.
Once removed, you should be able to open up the solution in VS and set things right in the configuration manager
The alternatives are to use a macro or VS EnvDTE classes to automate the process but that's perhaps the sledgehammer for a nut.
Normally I don't recommend doing this but you may need to take Notepad or your favourite XML editor and change the contents of your csproj file. The reason I don't like to recommend this approach is that if you get the editing wrong you can end up with a broken project.
Obviously you should back everything up before you start so you can at least get back to your current state if everything goes pear shaped.
Ideally you can dig into your Source Code Control system and get a copy of the csproj file from back when it wasn't broken and use that as a rough guide to what a well formed csproj file for your project looks like.
You can also create a completely new C# project using the same template as your project and use that project's csproj file as another guide to what things should look like.
If you're lucky your csproj file will contain a number of PropertyGroup items, some of which will have a condition identifying the particular build combination the group applies to. For example...
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
If you delete the groups for configurations you no longer want and delete any that seem to apply to x64 you may find that the build manager will let you add an x64 configuration.
I have a need to build a website and several DLLs that it references in an x86 configuration. To date we have been using Web Deployment Projects to create Zip files of the resultant site and all it's required files. We need to continue to use WDPs however, they seem to have problems with the x86 build configuration.
In my project, when I build the solution in Release/x86 I get the following error.
Description File Line Column Project
Error 80 Could not load type 'WwwRooot.Default'. /WwwRooot.csproj/Default.aspx 1 1 WwwRooot.csproj_deploy
There are no build errors or warnings from the web application or any of the referenced class libraries.
I thought this might be something specific to the project I'm working on so to prove myself wrong I created a solution containing a Web Application (c#). I then used the Configuration Manager to create the x86 configuration by copying the Any CPU config. I checked the properties page an made sure the new config was set to build to x86, and it was. I built the solution without error.
Next I right clicked the Web App and added a WDP from the context menu.
Right clicked on the WDP and edited the project file. At this point I changed any references for AnyCPU to x86 so that the WDP has conditions of x86 build.
I rebuilt the solution in Release/x86 and everything builds fine.
Next I add a Class Library, use Configuration Manager to create an x86 config for this library, add a reference to the web app for the library and then rebuild all in Release/x86 and I receive the same error as detailed above.
Are WDPs compatible with x86 build?
If I remove the Class Library (and the reference) the solution (including the WDP) builds fine.
I am using Visual Studio 2008 SP1, with the appropriate WDPs installed, on 64Bit Windows 7 Pro.
Out of the box, Web Deployment Projects (WDP) don't work with x86 or x64 build configurations. This is because a Web Application built under one of these configurations outputs the resultant assemblies in a different place and the WDP doesn't know to look there for the DLLs.
There are a few things you'll need to do to get the WDP working with your x86 configuration.
Firstly, your WDP probably doesn't have an x86 configuration, you'll need to create one. Edit the deployment project using the XML editor in Visual Studio (or any text editor), near the top of the file will see a <propertyGroup> tag (usually the second one) with a condition Debug|AnyCPU like so:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>.\Debug</OutputPath>
<EnableUpdateable>true</EnableUpdateable>
<UseMerge>true</UseMerge>
</PropertyGroup>
Duplicate this whole tag and change the configuration to be Debug|x84:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>.\Debug</OutputPath>
<EnableUpdateable>true</EnableUpdateable>
<UseMerge>true</UseMerge>
</PropertyGroup>
Now save the file and open the configuration manager (Build menu > Configuration manager) and check your deployment project now has an x86 configuration.
Now edit the Web Application Project file using your text editor and locate the outputPath element within the Debug|x86 configuration. It should have a value of Bin\x86\Debug. This needs changing to Bin:
<!-- Before -->
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
<OutputPath>Bin\x86\Debug\</OutputPath>
<!-- After -->
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
<OutputPath>Bin\</OutputPath>
Save, close and reload you Web Application Project. We've now instructed the Web Application to put it's DLLs where the WDP expects to find them.
Set your build configuration to x86 and build the project.
Rinse and repeat for Release and any other build configurations you might have.
Try this
Put this command in post compilation events of your web project
xcopy "$(TargetDir)*.*" "$(TargetDir)..\..\" /Y
This command wil copy files from bin\x86\Debug to bin
It will work with Release configuration
I would like the ability to have a test ClickOnce server for my applications where users can run both the production version and the test version in parallel. Is this possible?
I first tried using the following in AssemblyInfo.cs and also changing the name in the ClickOnce deployment though all this achieved was overwriting the users' production version with the test version. Likewise, it did the same when they went back to the production server.
#if DEBUG
[assembly: AssemblyTitle("Product Name - Test")]
#else
[assembly: AssemblyTitle("Product Name")]
#endif
I thought I should also clarify that the two deployment locations are different from one another and on different servers.
UPDATE
I've also tried setting the GUID for the manifest depending on the debug mode, but again it does not work (dummy GUID's used below).
#if DEBUG
[assembly: Guid("AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA")]
#else
[assembly: Guid("BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB")]
#endif
How are the two distinguished? It seems that the installer sees them as two separate programs as I get a confirmation of installation for each. Though, when I install the second one, "Add/Remove Programs" only sees the latter, though the former is still on disk, as when I go to reinstall it later, it just simply runs, but then the add/remove programs switches back to the former name.
It might sound kind of lame, but the easiest way to do this is to have two EXE projects in your solution. The Main method of each of these will just call the Main method in your original EXE project (which you'll have just switched over to being a DLL file).
This means that each EXE project can have its own ClickOnce publishing settings, as well as its own app.config file. This means you have different connection strings for the production and the test version.
Your other option (the one that might seem to make the most sense) is to use MageUI.exe to manually build the ClickOnce files, which would let you choose a different configuration file and publish location each time you ran the tool. There's also a command line version (Mage.exe) so you could in theory automate this.
However, we found that the solution with two "runner" projects was far far simpler. I'd recommend you try that first.
ClickOnce: Concurrent versions explains how to do this.
I manually edited the .csproj to specify a different ProductName for debug/release.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<PublishUrl>publishbeta\</PublishUrl>
<InstallUrl>http://www.softwareabc.com/download/beta/</InstallUrl>
<ProductName>Software ABC Test</ProductName>
<AssemblyName>SoftABCTest</AssemblyName>
<ApplicationIcon>Resources\Test.ico</ApplicationIcon>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
...
<PublishUrl>publish\</PublishUrl>
<InstallUrl>http://www.softwareabc.com/download/</InstallUrl>
<ProductName>Software ABC</ProductName>
<AssemblyName>SoftABC</AssemblyName>
<ApplicationIcon>Resources\Application.ico</ApplicationIcon>
</PropertyGroup>
One caveat is that Visual Studio 2010 doesn't update this if you switch between debug/release. It only takes effect when it loads the solution so make sure to switch debug/release then close and reopen the solution.
See the succinct video on concurrent versioning: ClickOnce: Concurrent versions.
Try changing the Assembly Name in the Application tab in the properties window.
I do that all the time. I even have a screen in my application that changes which version a specific user will get. And I'm not doing anything tricky on the app side, all the magic is on the web server hosting the ClickOnce files.
Take a look at the article my buddy wrote, Fine Grained Versioning with ClickOnce . It explains how we did it.
A variation on Peter Mortensen's two project scenario. I wanted dev, customer test, and customer release. In my case I wanted the customer test providing some visual clues that it was test, not live (e.g. 'TEST' in the title and a different visual theme).
I found it simplest to have two solutions as well as two stub projects. Each project in its own directory, with its own stub program.cs, app.config and assemblyinfo.cs.
In the dev/test solution, the debug configuration was for dev, the release config was for customer test. I used SlowCheetah to transform the app.config for the latter.
In the customer release solution I needed only a release config.
You have to edit your csproj manually, after having at least once configured your project to publish a Click Once application.
Move some of Click Once related properties from the <PropertyGroup> to the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> property group and duplicate them under the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> property group.
The properties to duplicate are ApplicationRevision (only if you want separate revision counters), PublishUrl, ProductName and SuiteName (the last two are required to be able to differentiate the configurations on the target machines). You also will have to override the AssemblyName property (without removing it from the first group).
If you want to be able to debug your project under any configuration, you also will have to add the StartAction and StartProgram properties in each group where you overrode the AssemblyName property.
After having given these properties adequate (i.e. different) values, you will be able to publish both configurations, without having to modify your project, just by selecting the desired configuration. Note however you will have to unload your project between publishes for different configurations, or Visual Studio will mess up your parameters.
After that, you also will be able to install both versions on the same target machine.
It is possible to deploy 2 versions of the same application without changing the AssemblyName, here is how it's done...
Create a clickonce deployment
Open the .application file and make the following edit:
3. Run the setup and MyApp will be installed. Depending on previous attempts you may need to clear the application cache with mage -cc
Edit the .application file again replacing MyApp with MyApp2
Run setup and MyApp2 will be installed