Conditional compilation new csproj and visual studio solution explorer - visual-studio

I have the following in my csproj file
<ItemGroup>
<Compile Remove="WebControls/**/*" Condition="'$(TargetFramework)' == 'netstandard2.0'" />
<Compile Remove="Lucene/**/*" Condition="'$(TargetFramework)' == 'netstandard2.0'" />
</ItemGroup>
I'm not even sure if this is the right approach, I'm trying to avoid having to go through those files and add a conditional compilation symbol such as "#if NET462".
The problem is that those files disappear from the solution explorer when I add that to csproj, is there a way to switch the target platform to net462 in the solution explorer so that they show again?

Related

Xamarin.Forms netstandard project broken with update to VS 2017.3

So today i made the mistake of updating my IDE to 2017.3.
I was then notified of incompatibilities such as
"NU1202: The package Xamarin.Forms 2.3.4.247 is not compatible with netstandard1.5. Package supports: list of targets such as monoandroid10, xamarinios10, etc"
After investigating the matter on google i found some information to try fix the project.
https://github.com/NancyFx/Nancy/issues/2647#issuecomment-265927440 suggests adding a frameworkmoniker to get it to build (At some point during fix attempts i had a platform warning too)
Another attempt i've made to fix the issue was recreating the project as a fresh template version of using a netstandard project (the project i've provided for repro was created during the time when project.json was still a thing)
You may ask why: While looking for the issue i read that some are false positive error messages, which can be disabled like this Package Reference Warning Ignore - However in this project type which is entirely based on .csproj again i was unable to add Xamarin.Forms 2.3.4.247.
So my question is:
Has anyone been able to get a similar project running on vs2017.3 yet?
REPRO project:
GitHub
After changing my project similar to a result of this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.5</TargetFramework>
<PackageTargetFallback>portable-net45+win8+wpa81+wp8</PackageTargetFallback>
</PropertyGroup>
<ItemGroup>
<EmbeddedResource Include="App.xaml">
<Generator>MSBuild:UpdateDesignTimeXaml</Generator>
</EmbeddedResource>
<EmbeddedResource Include="MainPage.xaml">
<Generator>MSBuild:UpdateDesignTimeXaml</Generator>
</EmbeddedResource>
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NETCore.Portable.Compatibility" Version="1.0.1" />
<PackageReference Include="Xamarin.Forms" Version="2.3.4.247" />
</ItemGroup>
<ItemGroup>
<Compile Update="App.xaml.cs">
<DependentUpon>App.xaml</DependentUpon>
</Compile>
<Compile Update="MainPage.xaml.cs">
<DependentUpon>MainPage.xaml</DependentUpon>
</Compile>
</ItemGroup>
</Project>
the project compiled again.
<PackageTargetFallback>portable-net45+win8+wpa81+wp8</PackageTargetFallback>
fixed the issue.

Teamcity .Net project, conditional project reference when building in Visual Studio

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".

Why is my cpp file not in the ClCompile index, causing LNK2019 and LNK2001 errors?

I was receiving LNK2019 and LNK2001 errors in VS 2010 but not with g++. I searched around looking for reasons but everything talked about making sure the right headers were included, the functions properly defined, etc.
After going to the project directory and opening the .vcxproj file I saw this list:
<ItemGroup>
<ClCompile Include="main.cpp" />
<ClCompile Include="pilElem3.cpp" />
... many lines ...
<ClCompile Include="utlMatrixFull.cpp" />
<ClCompile Include="utlVector.cpp" />
</ItemGroup>
<ItemGroup>
<ClInclude Include="pilElem3.h" />
... many lines ...
<ClInclude Include="utlMatrixFull.h" />
<ClInclude Include="utlVector.h" />
</ItemGroup>
<ItemGroup>
<None Include="pilElement.cpp" />
</ItemGroup>
pilElement is the parent class to pilElem3 and pilElem4 which were having the linker error.
I didn't change any of the filters or alter the project since creating it.
a) Why did VS think this file should be ignored?
b) How could I notice this sooner?
In answer to how I suspect that you may have inadvertently right clicked on the file in the project explorer - all to easy to do in VS.
How to make sure it doesn't happen in the future you have 2 options a) Don't use visual studio or b) Use a revision control system such as Mercurial and include the project file in those you are controlling - and do regular commits - you will be able to revert changes to the project file if needed and you should notice if it is in the changed file list when you are not expecting it to have changed.

Copy DLL files to bin directory after one-click publishing in VS2010

I have a web application in VS2010 which has a number of DLLs that need to be copied into the bin directory after doing a publish in VS2010.
I've tried putting the following into my .csproj file (which sits in the root folder of the web applications) but it doesn't seem to work:
<Target Name="AfterBuild">
<ItemGroup>
<_CircularDependencies Include="DLLs\Circular\Dependencies\*.dll" />
</ItemGroup>
<Copy
SourceFiles="#(_CircularDependencies)"
DestinationFiles="#(_CircularDependencies->'bin\%(Filename)%(Extension)')"
SkipUnchangedFiles="true" />
</Target>
For bonus points, I have another set of DLLs copied to be copied post-publish, but I want to use one set when doing a debug publish (for Win32) and a different set when doing a release publish (x86).
Thanks!
OK, I've managed to get this working fully. Thanks to the answers provided above, I've been able to add some MS Build commands to the .csproj file to copy the appropriate DLLs from various folders into the bin folder based on the current build configuration. However as these are unmanaged DLLs (i.e. not .NET) I can't create normal references to them and they fail to be copied during the publish. I got around this by dynamically adding the files to the project as 'content'.
The solution came in three parts. Firstly, create an item group for the files near the top of the .csproj file (I've tried to use generic filenames here to make it clearer), with conditions based on the current build configuration:
<ItemGroup Condition="'$(Configuration)' == 'Debug'">
<_UnmanagedDLLs Include="Win32DLLs\*.dll" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)' == 'Release'">
<_UnmanagedDLLs Include="x64DLLs\*.dll" />
</ItemGroup>
Then add another item group to include these DLLs (as content, not references) in the build:
<ItemGroup>
<Content Include="#(_UnmanagedDLLs->'bin\%(Filename)%(Extension)')" />
</ItemGroup>
Finally, at the bottom of the .csproj file, I do the copy on the AfterBuild target:
<Target Name="AfterBuild">
<Copy SourceFiles="#(_UnmanagedDLLs)" DestinationFiles="#(_UnmanagedDLLs->'bin\%(Filename)%(Extension)')" SkipUnchangedFiles="true" />
</Target>
It means I can do a debug publish for my windows 32 staging box and a release publish for my x64 production box while keeping my bin folder out of SVN.
Once you get the copy working, separate sets for debug/release is easy with a condition:
<ItemGroup Condition="'$(Configuration)' == 'Release'">
<_CircularDependencies Include="DLLs\Circular\Dependencies\*.dll" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)' == 'Debug'">
<_CircularDependencies Include="DebugDLLs\Circular\Dependencies\*.dll" />
<_CircularDependencies Include="DebugDLLs\Circular\Dependencies\*.pdb" />
</ItemGroup>
If you want your copy to happen after publish, not after build you need to change your target from:
<Target Name="AfterBuild">
to
<Target Name="AfterPublish">

Visual Studio: differentiate app.config for debug and release mode

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).

Resources