So I have a requirement where my project should use different GoogleServices files for Android/iOS while using different configurations like for eg while I am using the debug configuration it should use the debug version of the file and in the release, it should use the release version.
Something similar to
Xamarin firebase different google-services,json for different build configurations
When I follow the accepted the answer I get a compile-time error saying
The command COPY /Y "$(ProjectDir)GoogleServices\google-services-development.json" "$(ProjectDir)google-services.json" exited with code 1.
I tried clean build and cleaning bin/obj nothing changed.
So I tried the other solution mentioned here and what happens is the GoogleServices files(all of them) are excluded from the project and nothing happens if I build and run. I am unsure if this is even working or not.
I have added the following lines in my csproj for release and debug respectively
<ItemGroup Condition="'$(Configuration)'=='Debug'">
<GoogleServicesJson Include="Dev\google-services.json">
<Link>google-services.json</Link>
</GoogleServicesJson>
</ItemGroup>
<ItemGroup Condition="'$(Configuration)'=='Release'">
<GoogleServicesJson Include="Prod\google-services.json">
<Link>google-services.json</Link>
</GoogleServicesJson>
</ItemGroup>
Where dev and prod are root folders in my native android project
Any suggestions are welcome.
You have to edit *.csproj file.
Using a solution to use multiple Info.plist (LogicalName tag) and Condition tag you can play with any other files all you want.
For Android I added two *.json files to Resources folder and added this snippet to my *.csproj file:
<ItemGroup Condition=" '$(Configuration)' != 'Release' ">
<GoogleServicesJson Include="Resources\dev-google-services.json">
<LogicalName>Resources\google-services.json</LogicalName>
</GoogleServicesJson>
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)' == 'Release' ">
<GoogleServicesJson Include="Resources\release-google-services.json">
<LogicalName>Resources\google-services.json</LogicalName>
</GoogleServicesJson>
</ItemGroup>
In this example I use release-google-services.json for the "Release" build configuration, and dev-google-services.json for any other configurations.
Same for iOS. I added two *.plist files to root folder and added this snippet to my *.csproj file:
<ItemGroup Condition=" '$(Configuration)' != 'AppStore' ">
<BundleResource Include="Dev-GoogleService-Info.plist">
<LogicalName>GoogleService-Info.plist</LogicalName>
</BundleResource>
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)' == 'AppStore' ">
<BundleResource Include="Release-GoogleService-Info.plist">
<LogicalName>GoogleService-Info.plist</LogicalName>
</BundleResource>
</ItemGroup>
This approach works for me. I guess it doesn't matter where you put these files and how you name them. Just use the LogicalName that you need.
Also, you can combine it with other variables to compose more complicated conditions. For example, in order to build two *.apk in Release configuration with different *.json files you can:
<ItemGroup Condition=" '$(Configuration)|$(DynamicConstants)' != 'Release|' ">
<GoogleServicesJson Include="Resources\dev-google-services.json">
<LogicalName>Resources\google-services.json</LogicalName>
</GoogleServicesJson>
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(DynamicConstants)' == 'Release|' ">
<GoogleServicesJson Include="Resources\release-google-services.json">
<LogicalName>Resources\google-services.json</LogicalName>
</GoogleServicesJson>
</ItemGroup>
Build your project like this:
msbuild MobileApp.sln /p:Configuration=Release /p:DynamicConstants=DEBUG
When you use DEBUG parameter you build Release apk with dev-google-services.json.
When you omit DEBUG parameter you build Release apk with release-google-services.json.
Related
Using MSBuild how do i copy a file based on configuration of the build i.e. if the build configuration is Staging vs Release. I need to be able to copy FolderA\FileA if the build configuration is Staging and FolderB\FileB for production. Also the file when it gets copied should be at the root of the output directory instead in a folder as FolderA or FolderB. Using task is throwing errors during project load.
MSBuild - How to copy files based on condition
You can use Condition=" '$(Configuration)' == 'xxx' " for your copy task in the project file.
To accomplish this, unload your project. Then at the very end of the project, just before the end-tag </Project>, place below scripts:
<ItemGroup>
<MySourceFilesA Include="FolderA\FileA.txt" />
<MySourceFilesB Include="FolderB\FileB.txt" />
</ItemGroup>
<Target Name="CopyFiles" AfterTargets="Build">
<Copy SourceFiles="#(MySourceFilesA)" DestinationFolder="$(OutDir)" Condition=" '$(Configuration)' == 'Staging' " />
<Copy SourceFiles="#(MySourceFilesB)" DestinationFolder="$(OutDir)" Condition=" '$(Configuration)' == 'Release' " />
</Target>
You can modify the paht of SourceFiles and DestinationFolder according to your needs, just make sure the path is correct.
Hope this helps.
I have build chains in TeamCity, where the dependent artifact is copied to /bin directory of the main project. The project file references the artifact. That all works.
What I want is to allow a project file include, instead of the binary reference, when building/debugging from Visual Studio. I have tried some approaches, such as using conditionals in the project file, but is there a nice clean way to approach this?
May be there is the part of solution.
May way of using several referencing types of projs.
<ItemGroup Condition=" '$(ReferencedDACPAC)' == '' ">
<ProjectReference Include="..\OmniUS\OmniUS.sqlproj">
<Name>OmniUS</Name>
<Project>{26075a62-f6b0-40c3-baa2-b9a9829da3c4}</Project>
<Private>False</Private>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ProjectReference>
<ProjectReference Include="..\OmniUS_Finance_Jural\OmniUS_Finance_Jural.sqlproj">
<Name>OmniUS_Finance_Jural</Name>
<Project>{c8b0aee7-c2a4-4370-8451-13b455bb5363}</Project>
<Private>False</Private>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ProjectReference>
</ItemGroup>
<ItemGroup Condition=" '$(ReferencedDACPAC)' == 'true' ">
<ArtifactReference Include="..\DacPacs\OmniUS.sqlproj.dacpac">
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
<ArtifactReference Include="..\DacPacs\OmniUS_Finance_Jural.sqlproj.dacpac">
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
</ItemGroup>
When I build in TeamCity, I send ReferencedDACPAC as the "System" variable in the build, and thus refer to "ArtifactReference". When i build in VisualStudio, there is no var and the referencing occurs as "ProjectReference".
Problem
I've found that my TypeScript files only compile when I save them. However, when I build or rebuild the project, they do not compile. I'm using TypeScript 0.9.1.1.
When I check the build output of a new TypeScript project, it includes the following entry:
CompileTypeScript:
C:\Program Files\Microsoft SDKs\TypeScript\tsc.exe --module AMD --sourcemap --target ES3 "app.ts"
But my project doesn't produce this in its build output.
Setup
Here are the relevant parts of the project file:
<ItemGroup>
<TypeScriptCompile Include="Scripts\app\example.ts" />
</ItemGroup>
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
<TypeScriptTarget>ES5</TypeScriptTarget>
<TypeScriptIncludeComments>true</TypeScriptIncludeComments>
<TypeScriptSourceMap>true</TypeScriptSourceMap>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<TypeScriptTarget>ES5</TypeScriptTarget>
<TypeScriptIncludeComments>false</TypeScriptIncludeComments>
<TypeScriptSourceMap>false</TypeScriptSourceMap>
</PropertyGroup>
<Import Project="$(VSToolsPath)\TypeScript\Microsoft.TypeScript.targets" />
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
What I've checked
The files compile on build in new TypeScript projects, so it should be possible.
The targets file exists in the correct location
The project file configuration shown above appears to be correct when compared with a new TypeScript project
Compiling a new TypeScript project, which works fine
Cannot compile TypeScript files in Visual Studio 2012, but the symptoms of the problem are different to mine, and it's not clear if the author was using the same setup
Typescript will not properly compile in VS2012, but the symptoms of the problem are different to mine
The build action for each TypeScript file is set to TypeScriptCompile as shown above
After comparing the project file with a new TypeScript project file, I narrowed the problem down to the following:
The TypeScript targets file must be imported after the C# targets file.
In the code in the question, fix the problem by moving the following line up:
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
I have a bunch of ancillary XML and XSLT files that I want to edit and manage in visual studio.
The files do not logically belong under any code project in my solution and so in order to group them neatly, I have created a "dummy" C# dll project in visual studio and disabled it from building in Debug / release builds).
I wondered if there was a nicer way of achieving the same result (i.e. having all the files visible in solution explorer). What I think really want is a visual studio project type of "content only" but such a thing does not exist (or have I not looked hard enough?).
I have toyed with the idea of adding the files as solution items but then they seem harder to manage because creating a new "solution item folder" does not actually create a folder on disk.
Any one have any ideas?
Visual Studio 2015 has a project type called "Shared Project" which is essentially a content only project with no targets. It's listed under Visual C# but it can be used for any files.
A work colleague has come up with a solution.
He has suggested hand editing the project to remove the DefaultTargets from the Project (and delete a load of now unused properties).
MSBuild complains if there are no targets in the project so he has added three empty targets.
The final project looks something like this
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>9.0.30729</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{541463A7-7CFA-4F62-B839-6367178B16BD}</ProjectGuid>
</PropertyGroup>
<ItemGroup>
... files ...
</ItemGroup>
<ItemGroup>
... files ...
</ItemGroup>
<Target Name="Build"/>
<Target Name="Rebuild"/>
<Target Name="Clean"/>
</Project>
Admittedly, this solution requires more fiddling that I would have liked but seems to achieve what I was after: namely a project that does not aattempt to produce any build output.
Andy posted a link with a solution that's mostly worked for me; basically delete the following line from the project file:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
and add the following lines:
<Target Name="Build">
<Copy
SourceFiles="#(Content)"
DestinationFiles="#(Content->'$(OutputPath)%(RelativeDir)%(Filename)%(Extension)')" />
</Target>
<Target Name="Clean">
<Exec Command="rd /s /q $(OutputPath)" Condition="Exists($(OutputPath))" />
</Target>
<Target Name="Rebuild" DependsOnTargets="Clean;Build">
</Target>
I also found that disabling the project Debug property "Enable the Visual Studio hosting process" (for each configuration) prevented the MyProject.vshost.exe file from being generated.
As David I. McIntosh pointed out in a comment on this answer, if your project is part of a solution with multiple projects and any other projects use the same output path as the content-only project, the above Clean target will delete all of the files in the output path, i.e. the build output of other projects, and would thus only be correct if the content-only project is the first project built (among those sharing the same build output path). The following is a safer and friendlier Clean target for this scenario:
<Target Name="Clean">
<Delete Files="#(Content->'$(OutputPath)%(RelativeDir)%(Filename)%(Extension)')"/>
</Target>
Then, try creating a Blank solution. Create Empty project. Have your files in respective folders with in the solution folder. From property window, use the Show all files, include those folders into the project. There is no better solution other then this. I hope.
This answer is just a convenient consolidation of the answers above given by Chris Fewtrell and Kenny Evitt, along with the slight modification in my comments above, and a bit more detail on what the declaration of the content items should/could look like:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProjectGuid>{541463A7-7CFA-4F62-B839-6367178B16BD}</ProjectGuid>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == '64-bit|AnyCPU'">
<PlatformTarget>x64</PlatformTarget>
<OutputPath>..\builds\$(Configuration)\</OutputPath>
<IntermediateOutputPath>..\builds\$(Configuration)\Intermediate\YourProjectName\</IntermediateOutputPath>
</PropertyGroup>
<ItemGroup>
<Content Include="fileInProjectFolder.csv" />
<Content Include="SubDir\fileInSubdir.txt" />
<Content Include="..\actualSourceDirectoryOfFile\app.log.basic.config">
<Link>targetSubdirInOutputDir\app.log.basic.config</Link>
</Content>
<Content Include="..\actualSourceDirectoryOfFile\yetAnotherFile.config">
<Link>yetAnotherFile.config</Link>
</Content>
... more files ...
</ItemGroup>
<Target Name="Build">
<Copy
SourceFiles="#(Content)"
DestinationFiles="#(Content->'$(OutputPath)%(RelativeDir)%(Filename)%(Extension)')" />
</Target>
<Target Name="Clean">
<Delete Files="#(Content->'$(OutputPath)%(RelativeDir)%(Filename)%(Extension)')"/>
</Target>
<Target Name="Rebuild" DependsOnTargets="Clean;Build">
</Target>
</Project>
Note that this always copies all the "content" files to the output directory - the options "Copy If Newer", "Copy Always" and "Do Not Copy", as presented in the visual studio GUI ( appears as, for example, <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> in the .csproj file) are ignored.
In my situation, I needed to have a set of configuration files that would be common to many projects. To simply achieve this, I performed the following steps:
Create a Class Library project named "Configuration"
Delete all *.cs files from Configuration project
Put configuration files in a "Configuration" folder in the Configuration project
Copy configuration files to required projects in the post-build event. In Configuration project's Properties > Build Events > Post-build event:
xcopy "$(TargetDir)Configuration\*" "$(SolutionDir)TARGET_PROJECT\$(OutDir)" /i /v /q /s /y
In the above, replace TARGET_PROJECT with your actual project
This will copy all the files in the Configurations folder to the output directory of the project that needs the configuration files (eg. MyProject/bin/Debug, etc).
Is there a way to automatically use a separate app.config when building in release mode?
In other words, I want to test with one app.config, and release with another.
Currently, I keep a separate copy called app.config.production, and manually overwrite bin\Release\Application.exe.config after building for release.
Unload the project in Solution Explorer via the context menu.
Edit the .csproj file via the context menu and add this:
<PropertyGroup>
<AppConfig>App.$(Configuration).config</AppConfig>
</PropertyGroup>
I have recently posted a supremely belated response to a similar SO topic:
https://stackoverflow.com/a/27546685/2798367
I will repeat it here for clarity:
This is somewhat late to the party, but I stumbled upon a nice way of implementing the web.transform approach for app.config files. (i.e. it makes use of the namespace http://schemas.microsoft.com/XML-Document-Transform)
I think it is "nice" because it is a pure xml approach and doesn't require 3rd party software.
A parent / default App.config file is descended from, according to your various build configurations.
These descendants then only override what they need to.
In my opinion this is much more sophisticated and robust than having to maintain x number of config files which get copied in their entirety, such as in other answers.
A walkthrough has been posted here: http://mitasoft.wordpress.com/2011/09/28/multipleappconfig/
Look, Mom - No explicit post-build events in my IDE!
A clean solution is to group 2 files App.Debug.config and App.Release.config into App.config and change the good file into App.config depending on the configuration at compile time:
<ItemGroup>
<None Include="App.config" />
<None Include="App.Debug.config">
<DependentUpon>App.config</DependentUpon>
</None>
<None Include="App.Release.config">
<DependentUpon>App.config</DependentUpon>
</None>
</ItemGroup>
<Target Name="SetAppConfig" BeforeTargets="Compile">
<Copy SourceFiles="App.Debug.config" DestinationFiles="App.config" OverwriteReadOnlyFiles="true" Condition=" '$(Configuration)' == 'Debug' " />
<Copy SourceFiles="App.Release.config" DestinationFiles="App.config" OverwriteReadOnlyFiles="true" Condition=" '$(Configuration)' == 'Release' " />
</Target>
With this solution you will get something like this in Visual Studio:
A simple and fast way is to create a second file "App.release.config" and insert this pre-build event:
IF $(ConfigurationName) == Release COPY /Y "$(ProjectDir)App.config" "$(ProjectDir)App.debug.config"
IF $(ConfigurationName) == Release COPY /Y "$(ProjectDir)App.release.config" "$(ProjectDir)App.config"
And this post build event:
IF $(ConfigurationName) == Release COPY /Y "$(ProjectDir)App.debug.config" "$(ProjectDir)App.config"
This might be a bit odd, but it will allow you to keep using the .Settings files as debug settings, that are still linked to the App.config. The App.release.config must be build by hand, but it's pretty easy to switch this functionality.
I highly recommend SlowCheetah for app.config transformations. Visit this nuget gem here Visual Studio Gallery
Similar to top answer but with this approach you can see the actual file if preferred and intellisense doesn't complain in csproj file:
<Target Name="SetAppConfig" BeforeTargets="Compile">
<Copy SourceFiles="debug.config" DestinationFiles="app.config" OverwriteReadOnlyFiles="true" Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' " />
<Copy SourceFiles="release.config" DestinationFiles="app.config" OverwriteReadOnlyFiles="true" Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " />
</Target>
I don't know if this helps, but app.config will recognise the standard MSBUILD substitution strings such as $(Configuration).