We Keep Coding

Multi-Targeting with Conditions Causes NuGet Fail?

I have a project that is using NuGet packages. It also needs to target different framework versions per build config. I have them laid out in my csproj file something like this:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == '2018|x64'">
<OutputPath>..\BuildFolder\2018</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == '2019|x64'">
<OutputPath>..\BuildFolder\2019</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<TargetFrameworkVersion>v4.7</TargetFrameworkVersion>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
I have more build configs than that, but those are examples where I have two different frameworks. The issue is that when I try to batch build the project with all release configs half of them fail depending on what my current config is. Using the two above, I can switch VS to my 2018 configuration and do a NuGet restore, then batch build both and 2018 will work and 2019 will fail with a 'Your project does not reference .NET Framework 4.7' errors. If I then switch to the 2019 config and do a NuGet restore and then try to batch build I get the reverse; 2019 works and 2018 tells me 'Your project does not reference .NET Framework 4.6.1'.
I also tried to put in the 'TargetFrameworks' object in the csproj file but then VS just spins and spins on opening and never opens the project.
How do I get this to work and recognize it to build all configs in batch? I suppose I could build them individually and will have to for now but that seems laborious and unnecessary...

Visual Studio C# project in Monodevelop - Errors for GenerateSatelliteAssemblies and GenerateTargetFrameworkMonikerAttribute

I am trying to setup a C# project that is compatible with both Windows 10 / Visual Studio 2015 and Ubuntu 16.04 / MonoDevelop.
In the MonoDevelop project options, I set the target framework to Mono / .NET 4.5 and configuration to Debug|x86.
The .csproj file now looks like this:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProjectGuid>{myprojectsguid}</ProjectGuid>
<OutputType>Exe</OutputType>
<RootNamespace>myproject</RootNamespace>
<AssemblyName>myproject</AssemblyName>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug</OutputPath>
<DefineConstants>DEBUG;</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<Externalconsole>true</Externalconsole>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<DebugType>full</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release</OutputPath>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<Externalconsole>true</Externalconsole>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
<ItemGroup>
<Reference Include="System" />
</ItemGroup>
<ItemGroup>
<Compile Include="Program.cs" />
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
</Project>
When I build, I get this message:
Erzeuge Projektmappe: myproject (Debug|x86)
myproject (Debug|x86) wird erzeugt
Build started 26.05.2016 22:05:49.
__________________________________________________
Project "pathto/myproject.csproj" (Build target(s)):
Target PrepareForBuild:
Configuration: Debug Platform: x86
Target GenerateSatelliteAssemblies:
No input files were specified for target GenerateSatelliteAssemblies, skipping.
Target GenerateTargetFrameworkMonikerAttribute:
Skipping target "GenerateTargetFrameworkMonikerAttribute" because its outputs are up-to-date.
Done building project "pathto/myproject.csproj".-- FAILED
Build FAILED.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.0785520
--------------------- Fertig ---------------------
Erzeugung erfolgreich.
The message seems to contradict itself. The English part says "build failed", while the localized/German part says "build successful". But no executable was created.
I did not find any applicable information about GenerateSatelliteAssemblies or GenerateTargetFrameworkMonikerAttribute.
Do I need to change the project settings even further? Do I need to supply some missing files?
Update:
Apparently, some packages were missing. So I ran sudo apt-get install mono-complete. Now the project builds successfully.
Though, the notifications about GenerateSatelliteAssemblies and GenerateTargetFrameworkMonikerAttribute are still there. Looks like they don't break the build. I still wonder what they mean.

(I'm just posting the answer that the asker wrote in the question.)
For the asker, it turned out that some packages were missing. The asker ran sudo apt-get install mono-complete, and then the project would build successfully.

How can a project be built as a portable or a normal class library depending on the selected configuration?

Context: We have a common library project called 'THEPROJECT' that is shared with a Xamarin mobile solution and a web project in visual studio. This shared library is a PCL Profile259 due to restrictions in Xamarin. In our web application solution we would like to mark the data models with the appropriate attributes for DataContext to work correctly (as we want to use LinqToSql).
Attempted Solution: We decided to look into the project for 'THEPROJECT' and change the msbuild in a way that would allow it to exist in a state of portable library / normal class library depending on the selected configuration in visual studio.
We have looked at the solution in this post however it is only part of the solution. We can get the project to exist as one or the other, however it requires a manual change to the project file. Now we get the error loading the following project. The for a portable project must be '.NETPortable'.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">DebugDesktop</Configuration>
<Platform Condition="'$(Platform)' == ''">AnyCPU</Platform>
<ProjectGuid>{426E7BD8-9DA8-4E15-9512-72E7C632B037}</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>THEPROJECT</RootNamespace>
<AssemblyName>THEPROJECT</AssemblyName>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<MinimumVisualStudioVersion>10.0</MinimumVisualStudioVersion>
<BuildMode>Desktop</BuildMode>
</PropertyGroup>
<!-- Define the Build Configurations -->
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'DebugDesktop|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Desktop\Debug\</OutputPath>
<DefineConstants>TRACE;DEBUG;</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<ConsolePause>false</ConsolePause>
<BuildMode>Desktop</BuildMode>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'ReleaseDesktop|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Desktop\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<BuildMode>Desktop</BuildMode>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'DebugPCL|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\PCL\Debug\</OutputPath>
<DefineConstants>TRACE;DEBUG;</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<ConsolePause>false</ConsolePause>
<BuildMode>Portable</BuildMode>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'ReleasePCL|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\PCL\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<BuildMode>Portable</BuildMode>
</PropertyGroup>
<!-- Determine the correct properties for PCL/Desktop -->
<Choose>
<When Condition=" '$(BuildMode)' == 'Portable' ">
<PropertyGroup>
<ProjectTypeGuids>{786C830F-07A1-408B-BD7F-6EE04809D6DB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
<TargetFrameworkProfile>Profile259</TargetFrameworkProfile>
<TargetFrameworkIdentifier>.NETPortable</TargetFrameworkIdentifier>
<DynamicImportPath>$(MSBuildExtensionsPath32)\Microsoft\Portable\$(TargetFrameworkVersion)\Microsoft.Portable.CSharp.targets</DynamicImportPath>
</PropertyGroup>
</When>
<When Condition=" '$(BuildMode)' == 'Desktop' ">
<PropertyGroup>
<FileAlignment>512</FileAlignment>
<TargetFrameworkProfile />
<DynamicImportPath>$(MSBuildToolsPath)\Microsoft.CSharp.targets</DynamicImportPath>
</PropertyGroup>
<ItemGroup>
<Reference Include="System.Data.Linq" />
</ItemGroup>
</When>
</Choose>
<ItemGroup>
<Reference Include="Newtonsoft.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\..\mobileapplication\packages\Newtonsoft.Json.8.0.2\lib\portable-net40+sl5+wp80+win8+wpa81\Newtonsoft.Json.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="System.Xml.Linq" />
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Xml" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\..\sqlite-net-extensions\SQLiteNetExtensions\SQLiteNetExtensions-PCL.csproj">
<Project>{f723017d-ede5-49cc-a84f-881c067c6004}</Project>
<Name>SQLiteNetExtensions-PCL</Name>
</ProjectReference>
<ProjectReference Include="..\..\sqlitenetpcl\src\SQLite.Net\SQLite.Net.csproj">
<Project>{4971d437-0694-4297-a8cc-146ce08c3bd9}</Project>
<Name>SQLite.Net</Name>
</ProjectReference>
</ItemGroup>
<Import Project="$(DynamicImportPath)" />
<!-- Source/Resx etc... -->
</Project>

To answer the question about making a project be "Portable" or "Normal" depending on the configuration, when the error that pops up is something about the <TargetFrameworkIdentifier> must be .NETPortable:
Remove all the <ProjectTypeGuids> from the configuration.
Those project type GUIDs give Visual Studio some GUI things that have to do with portable projects only, so when the configuration is not portable it causes the error you got. But since you're comfortable editing the XML, you obviously don't need that stuff. Plus you can continue to use the GUI to edit project properties with the project type GUIDs removed.
At least as of Visual Studio 2015.

When you create a Portable Class Library you need to create your library as a Windows 8.1 Portable Library you can't use Universal Libraries for this, which it sounds like you did by the constraints of Xamarin. The Windows 8.1 Portable Library is a kind of hybrid library that allows classic .net to communicate with the new lightweight versions of .net.
The issue with the Portable Class Library is it can't reference a a Classic Class Library via project reference, you can only reference it via DLL reference. You do not need to mess around with the XML if you are uncomfortable editing that file just find the compiled DLL and add the reference manually. If you choose to do this you will need to manually update the build dependencies or you may have broken references.
It seems like the issue isn't entirely in your .csproj but it is also in your project.json. I have been noticing visual studio not generating the proper project.json file. I have to tinker with the targets in the UI to get it to generate correctly. Once I get the initial project.json to generate I have no other issues.
Prior to doing anything we need to wire up our Portable Class Library to handle a Classic Class Library. The first step is updating the target framework from the properties to target .net 4.5 or whatever version you prefer.
Once you do this confirm that the project.json file looks something like this:
{
"supports": {},
"dependencies": {},
"frameworks": {
".NETPortable,Version=v4.5,Profile=Profile259": {}
}
}
Once your Portable Class Library is targeting the correct version you can then add a DLL reference to the compiled .net 4.5 assembly. I have made no additional changes to the csproj file for the portable class library but here is the source to that so you can take a look.
Notice how the ClassLibrary1 is referenced:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<PropertyGroup>
<MinimumVisualStudioVersion>11.0</MinimumVisualStudioVersion>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProjectGuid>{7C4EB968-4C17-438C-B981-97EDC865F312}</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>PortableLibrary</RootNamespace>
<AssemblyName>PortableLibrary</AssemblyName>
<DefaultLanguage>en-US</DefaultLanguage>
<FileAlignment>512</FileAlignment>
<ProjectTypeGuids>{786C830F-07A1-408B-BD7F-6EE04809D6DB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
<TargetFrameworkProfile>Profile259</TargetFrameworkProfile>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<ItemGroup>
<Compile Include="Class1.cs" />
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>
<ItemGroup>
<Reference Include="ClassLibrary1">
<HintPath>..\ClassLibrary1\bin\Debug\ClassLibrary1.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<None Include="project.json" />
</ItemGroup>
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\Portable\$(TargetFrameworkVersion)\Microsoft.Portable.CSharp.targets" />
<!-- To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Microsoft.Common.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->
</Project>
This should eliminate issues assuming your web project is ASP.NET Core 1.0. If you are running a Classic ASP.NET application you may still have to create the build rules.
TLDR:
Looks like there is an issue with your project.json file, make sure it is getting generated correctly and you can't directly reference .net 4.5 via project reference you have to reference the DLL.

C# project additional output path

In project file, normally we can see the following for setting the project output path. Now I am wondering if there is a way to set additional output path. i.e., the built binaries will be copied to the additional path as well.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>

It would be trivial to add a post-build event to your project/solution configuration, which copies the files from the original build location to your specified new one. Go to your project properties, and under "Build Events" add the following to your post-build event command line:
xcopy /E $(ProjectDir)bin\Release\ [pathToMyDestination]
As an aside, I'm guessing you want to publish your release build to a host. In that case it's worth looking into continuous integration software, which gives you powerful capabilities. We've used several and are currently using Team City (free).

Conditional references in .NET project, possible to get rid of warning?

I have two references to a SQLite assembly, one for 32-bit and one for 64-bit, which looks like this (this is a test project to try to get rid of the warning, don't get hung up on the paths):
<Reference Condition=" '$(Platform)' == 'x64' " Include="System.Data.SQLite, Version=1.0.61.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=AMD64">
<SpecificVersion>True</SpecificVersion>
<HintPath>..\..\LVK Libraries\SQLite3\version_1.0.65.0\64-bit\System.Data.SQLite.DLL</HintPath>
</Reference>
<Reference Condition=" '$(Platform)' == 'x86' " Include="System.Data.SQLite, Version=1.0.65.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=x86">
<SpecificVersion>True</SpecificVersion>
<HintPath>..\..\LVK Libraries\SQLite3\version_1.0.65.0\32-bit\System.Data.SQLite.DLL</HintPath>
</Reference>
This produces the following warning:
Warning 1 The referenced component 'System.Data.SQLite' could not be found.
Is it possible for me to get rid of this warning?
One way I've looked at it to just configure my project to be 32-bit when I develop, and let the build machine fix the reference when building for 64-bit, but this seems a bit awkward and probably prone to errors.
Any other options?
The reason I want to get rid of it is that the warning is apparently being picked up by TeamCity and periodically flagged as something I need to look into, so I'd like to get completely rid of it.
Edit: Per the answer, I tried this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
...
<SqlitePath>..\..\LVK Libraries\SQLite3\version_1.0.65.0\32-bit</SqlitePath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
...
<SqlitePath>..\..\LVK Libraries\SQLite3\version_1.0.65.0\32-bit</SqlitePath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
...
<SqlitePath>..\..\LVK Libraries\SQLite3\version_1.0.65.0\64-bit</SqlitePath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
...
<SqlitePath>..\..\LVK Libraries\SQLite3\version_1.0.65.0\64-bit</SqlitePath>
</PropertyGroup>
and then in my reference:
<Reference Include="System.Data.SQLite">
<SpecificVersion>False</SpecificVersion>
<HintPath>$(SqlitePath)\System.Data.SQLite.DLL</HintPath>
</Reference>
This got rid of the warning, but is it correct?

If there is no "AnyCPU" assembly for SQL Lite you are stuck with separate builds.
To do separate builds create a property that gives the correct path in a conditional property group and then use that property to have a single reference (i.e. move the conditional outside the references items group). There is an example of using such a property (for a custom FXCop extension) here, you can see lots of conditional properties being defined at the start of the .csproj file.
(Summary: VS doesn't handle all of the possibilities MSBuild does.)

As I see it, the problem with your original project was that you had <SpecificVersion>True</SpecificVersion> specifying System.Data.SQLite, Version=1.0.61.0, whereas the actual assembly was version 1.0.65. Fixing version in the assembly name in Reference ought to help.