We Keep Coding

Create nuget package for multiple SDK projects

I have 3 .net standard SDK projects(Utils, Reporting and Testing) that I want to pack them into one nuget package called Shared and upload it in my local package management system to be able to be used in my other projects. I was thinking to use the csproj file(s) to fill all the package information so I don't have to use nuspec file(s). One way I tried is to create a new .net standard project called Shared that references all the first 3 projects and only fill the Shared.csproj.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<Copyright>Copyright (c) Me</Copyright>
<GeneratePackageOnBuild>False</GeneratePackageOnBuild>
<SkipCopyBuildProduct>true</SkipCopyBuildProduct>
<GenerateDependencyFile>False</GenerateDependencyFile>
<DebugSymbols>false</DebugSymbols>
<DebugType>none</DebugType>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\Utils.csproj" />
<ProjectReference Include="..\Reporting.csproj" />
<ProjectReference Include="..\Testing.csproj" />
</ItemGroup>
</Project>
I've tried this msbuild command:
dotnet msbuild -t:pack=Shared.csproj;-p:Configuration=Release;PackageOutputPath=.\release;
and this nuget cli command:
nuget pack Shared.csproj -Build -IncludeReferencedProjects -Prop Configuration=Release
but they don't work. I'm not sure which one is more suited.
Are there more suited alternatives?
Later edit: I've added my code to github with #mu88's suggestion to not create a project only for grouping my other projects but I don't get the 3 projects in my nupkg's libs folder. Do I also specify each project in the dependencies.group section?

I'd personally recommend using a .nuspec file - using a project only as a container to ship multiple assemblies together without any behavior at all doesn't seem right to me.
Such a .nuspec would look like this:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>My.Package</id>
<version>1.0.0</version>
<description>My package</description>
<authors>Me</authors>
<dependencies>
<group targetFramework="netstandard2.0" />
</dependencies>
</metadata>
<files>
<file src="*\bin\Debug\netstandard2.0\*.dll" target="lib\netstandard2.0" />
</files>
</package>
And you have to call nuget pack .\.nuspec (using PowerShell).
The newer approach would be to not use .nuspec at all, but ship the three projects as three independent NuGet packages.

Consuming nuget package made with .nuspec and .targets (C++)

Struggling to get a compiled c++ dll (both x86 and x64) packaged up so that a C# library can consume it.
Managed to pack and push the dll using nuspec file however when using VS2019 package manager it successfully installs the package however the reference does not appear. (Any Cpu)
.nuspec
<?xml version="1.0"?>
<package >
<metadata>
<id>component1</id>
<version>1.0.0</version>
<description>mycomponent</description>
<authors>Me</authors>
</metadata>
<files>
<file src="32\component1.dll" target="build\x86" />
<file src="64\component1.dll" target="build\x64" />
<file src="component1.targets" target="lib\net40" />
</files>
</package>
As the consuming project is targeting .NET 4.0 I created a component1.targets file pointing to the same framework
.targets
<ItemGroup Condition=" '$(Platform)' == 'x64' ">
<Reference Include="component1">
<HintPath>"$(MSBuildThisFileDirectory)..\..\build\x64\component1.dll"</HintPath>
</Reference>
</ItemGroup>
<ItemGroup Condition=" '$(Platform)' == 'x86' OR '$(Platform)' == 'AnyCPU' OR '$(Platform)' == 'Any CPU' ">
<Reference Include="component1">
<HintPath>$(MSBuildThisFileDirectory)..\..\build\x32\component1.dll</HintPath>
</Reference>
</ItemGroup>

Your steps are in a mess.
You should note that the targets file should be named as <package_id>.targets`, the same name as the nuget package id or it could not work. See this link.
Also, the targets file should be put into build folder of nupkg.
That are the two importance tips.
1) Please change your nuspec file to this:
<?xml version="1.0"?>
<package >
<metadata>
<id>component1</id>
<version>1.0.0</version>
<description>mycomponent</description>
<authors>Me</authors>
</metadata>
<files>
<file src="32\component1.dll" target="build\x86" />
<file src="64\component1.dll" target="build\x64" />
<file src="component1.targets" target="build" />
</files>
</package>
2) Then, change your component1.targets to these:
You should remove the "" under "$(MSBuildThisFileDirectory)..\..\build\x64\component1.dll".
<Project>
<ItemGroup Condition=" '$(Platform)' == 'x64' ">
<Reference Include="component1">
<HintPath>$(MSBuildThisFileDirectory)..\build\x64\component1.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup Condition=" '$(Platform)' == 'x86' OR '$(Platform)' == 'AnyCPU' OR '$(Platform)' == 'Any CPU' ">
<Reference Include="component1">
<HintPath>$(MSBuildThisFileDirectory)..\build\x32\component1.dll</HintPath>
</Reference>
</ItemGroup>
</Project>
3) use nuget pack to repack the nuget package. And before you install this new version of the nuget package, please clean nuget caches first or just delete all files under C:\Users\xxx(current user name)\.nuget\packages.
And it works well in my side.
My nuget package is called testt, and I referenced ClassLibrary21.dll under x64.

MSBuild targets for nuget project called from another project

I am a beginner with MSBuild. I have a project (A) that depends on another project (B) and it consumes it either from a NuGet server either from a local workspace (I use NuGetReferenceSwitcher for this purpose).
Shortly, here are my requirements:
When consumed from NuGet server, project B has to support both Debug and Release builds. In this way, if we switch to Debug in Visual Studio we would be able to debug also project B when called from A. Right now, the NuGet also gives the Release version.
When switching to local workspace, it should still build properly.
Here is how my local files are located:
\workspace\projectA\projectA.sln
\workspace\projectB\projectB.csproj
The solution I tried is the following:
Inside projectB I created a targets file (located in build\projectB.targets) with the following contents:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup Condition="'$(Configuration)' == 'Debug'">
<Reference Include="lib1">
<HintPath>"$(MSBuildProjectDirectory)\bin\$platform$\Debug\lib1.dll"</HintPath>
</Reference>
</ItemGroup>
<ItemGroup Condition="'$(Configuration)' == 'Release'">
<Reference Include="lib1">
<HintPath>"$(MSBuildProjectDirectory)\bin\$platform$\Release\lib1.dll"</HintPath>
</Reference>
</ItemGroup>
</Project>
projectB.csproj contains this:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="packages\some_package" Condition="Exists('packages\some_package)" />
projectB.nuspec contains:
<file src="build\**" target="build\net462" />
projectA.csproj (that depends on projectB) contains:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="..\packages\projectB.*\build\projectB.targets" Condition="Exists('..\packages\projectB.*\build\projectB.targets')" />
<Import Project="..\..\..\..\projectB\projectB.csproj" Condition="!Exists('..\packages\projectB.*\build\projectB.targets')" />
Here are my questions:
With this configuration, when using local workspace for projectB, the compilation of projectA fails because of the relative path of "some_package" which is not find from projectA (that also uses relative path for projectB as you see in point 4). How else could I do reference projectB from projectA so it doesn't fail the compiling?
Why is this code not working to switch from release to debug when using nuget?
Thank you,

Why is this code not working to switch from release to debug when using nuget?
Quite simply, NuGet doesn't have a concept of "Debug" or "Release".
However, there is a way to create debug symbols for NuGet packages and then configure Visual Studio to step through the code of the installed packages.

Msbuild for copying assemblies to a few folders of applications?

I have a VS solution that contains a few applications and public APIs to be published along with shared libraries. I have some shallow experience in crafting msbuild file like this one.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<PropertyGroup>
<Configuration>Release</Configuration>
<Platform>Any CPU</Platform>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<TPath>C:\Program Files (x86)\MSBuild\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks</TPath>
<ETPath>C:\Program Files (x86)\MSBuild\ExtensionPack\4.0\</ETPath>
</PropertyGroup>
<ItemDefinitionGroup />
<ItemGroup>
<SolutionFile Include="MyApplications.sln" />
</ItemGroup>
<Target Name="Build" Outputs="#(CollectedBuildOutput)">
<MSBuild Projects="#(SolutionFile)" Targets="Rebuild" BuildInParallel="True"
Properties="BuildingSolutionFile=true; Configuration=$(Configuration); Platform=$(Platform); TargetFrameworkVersion=$(TargetFrameworkVersion); WarningLevel=3"
SkipNonexistentProjects="%(ProjectReference.SkipNonexistentProjects)">
<Output TaskParameter="TargetOutputs" ItemName="CollectedBuildOutput"/>
</MSBuild>
</Target>
</Project>
Then I run
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe MyProjects.msbuild /p:outdir=C:\VSProjectsRelease\MyApplications\Release\
So all assemblies will go to the same directory. So far so good. However, if I want to zip files for each application, or harvest files for Wix setup projects, troubles will emerge.
For example, in MyApplications.sln, I have 10 projects, 3 of which are applications say AppA, AppB and AppC.
I would like to run a single msbuild file which will create 3 folders of applications, and have assemblies copied to there without explicitly defining dependencies since Sln and csproj files already have the knowledge. And I would want msbuild will build each project only once. How to do this?

MSBUILD target outputs element is applied strangly [duplicate]

I have customised an MSBuild project so that the default target is a new target named similarly to 'BuildWithExternalReference'. This new target calls two other targets; the first is a custom target called something like 'BuildExternalReference' which builds a DLL using an external tool. The DLL that is built is a reference for the main project, which is built using the normal 'Build' target. I have setup the Inputs and Outputs attributes for the 'BuildExternalReference' target so the Inputs reference the source files and the outputs reference the resulting DLL.
In both Visual Studio 2012 and Visual Studio 2010 the build works correctly the first time it is invoked. However, on subsequent builds if I change the external source files (referenced by the 'BuildExternalReference' target Inputs attribute) then Visual Studio 2012 simply reports 'Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped'. Visual Studio 2010 continues to work perfectly. In addition, building from the command line with MSBuild.exe works perfectly.
I'm aware that the build system in Visual Studio 2012 has changed, but I can't find information about changes to the way incremental builds are performed.
Has anything changed in Visual Studio 2012 to cause incremental builds to change?
Here's a cut down version of the csproj file I'm using:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="BuildWithExternalTool" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<ExternalSourceFiles Include="..\ExternalSourceFiles\\*\*.cs" />
<ExternalDll Include="..\ExternalSource\External.dll" />
</ItemGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Target Name="BuildExternalTool" Inputs="#(ExternalSourceFiles);" Outputs="#(ExternalDll)">
<Exec Command="C:\External\Path\To\Tool.exe" />
</Target>
<Target Name="BuildWithExternalTool">
<CallTarget Targets="BuildExternalTool" />
<CallTarget Targets="Build" />
</Target>
</Project>
Update 1st of November 2012
Here's a complete self contained example which reproduces the issue:
https://skydrive.live.com/redir?resid=EA1DD6ACA92F9EFF!155&authkey=!ANhuqF_rrCgxpLE
This is a solution with one project. The MSBuildIssueExample\MSBuildIssueExample.csproj file has been customised so there is a custom default target. This default target calls a custom target (called 'ExternalTool') and then the default Build target.
The custom ExternalTool target writes out some messages to make sure it's working, and also copies the contents of the MSBuildIssueExample\ExternalTool\Input.txt file over the MSBuildIssueExample\ExternalTool\Output.txt file.
The Input.txt file is a input of the ExternalTool target, and Output.txt is an output.
To recreate the issue follow these steps:
1) Open the solution in the designated version of Visual Studio
2) Build the solution once to make sure the outputs are up to date with respect to the inputs
3) Modify MSBuildIssueExample\ExternalTool\Input.txt so its content does not match Output.txt
4) Build again
When you go through this process in Visual Studio 2010 the ExternalTool target will be invoked again, and the Input.txt file will be copied over Output.txt.
When you go through this process in Visual Studio 2012 the ExternalTool target will not be invoked, even though the inputs are newer than the outputs, and as a result the contents of Input.txt will not be written to Output.txt.
However, if you do Rebuild (rather than just Build) then both versions of Visual Studio work as expected.

This feedback from Microsoft answers the question:
This is due to a change in VS 2012 where C#/VB projects now do a "fast up-to-date check" that allows them to skip the build, rather than forcing the build all the time. One downside, however, is that fast up-to-date check does not take into account custom targets, which is why your incremental change was not detected. If you wish to disable the "fast up-to-date check" please set "DISABLEFASTUPTODATECHECK" to true either as an MSBuild property in the project file or as an environment variable in the environment you launch VS from.
So basically this is a breaking change in Visual Studio 2012 that unfortunately does not seem to be documented very well.

This is an old issue, but still relevant. Thank you very much for raising it here.
I would like to provide the results of my research.
The example you share shows the abnormal behavior both when built inside the Visual Studio GUI and by the devenv command line (devenv .\MSBuildIssueExample.sln /build)
However, if you replace your csproj file with the following:
MSBuildIssueExample.csproj
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>8.0.30703</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{4EA8847D-262C-4937-8536-E526E9BAB1C7}</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>MSBuildIssueExample</RootNamespace>
<AssemblyName>MSBuildIssueExample</AssemblyName>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
</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>
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="System.Xml.Linq" />
<Reference Include="System.Data.DataSetExtensions" />
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Data" />
<Reference Include="System.Xml" />
</ItemGroup>
<ItemGroup>
<Compile Include="Class1.cs" />
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="Custom.Targets" />
</Project>
Custom.Targets
<?xml version="1.0" encoding="utf-8" ?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CompileDependsOn>ExternalTool;$(CompileDependsOn)</CompileDependsOn>
<CleanDependsOn>CleanOutput;$(CleanDependsOn)</CleanDependsOn>
</PropertyGroup>
<ItemGroup>
<ExternalToolInputs Include="ExternalTool\Input.txt">
<InProject>false</InProject>
</ExternalToolInputs>
<ExternalToolOutputs Include="ExternalTool\Output.txt">
<InProject>false</InProject>
</ExternalToolOutputs>
</ItemGroup>
<Target Name="ExternalTool" Inputs="#(ExternalToolInputs)" Outputs="#(ExternalToolOutputs)">
<Message Text="ExternalTool target start, copying input file over output..." />
<Copy SourceFiles="#(ExternalToolInputs)" DestinationFiles="#(ExternalToolOutputs)" />
<Message Text="ExternalTool target end, copy successful" />
</Target>
<Target Name="CleanOutput">
<Delete Files="#(ExternalToolOutputs)" ContinueOnError="true" />
</Target>
</Project>
Then the behavior is different !
Visual Studio GUI continues to misbehave, however, the command line build with devenv does recognize the change in the input!
Also note, that running msbuild on the command line instead of devenv works correctly in both versions. Although msbuild has other problems ...
EDIT
There is a solution for the GUI build, which is only applicable when the amount of external files is small. You add them to the project as links and make sure the Build Action is None. Then it works fine in the GUI.
Although, I have only checked with the Custom.Targets, but I am pretty sure it is going to work with the original version as well.

To expand on mark's Edit, and since None-items didn't work for me, here's an example of a custom targets file that I can import in other projects, that reads a text file into a property (which I can then use in the DefineConstants property), and that will mark the text file as input for the CoreCompile target:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CommonDefines>$([System.IO.File]::ReadAllText('$(SolutionDir)\_meta\definesFlags.txt'));$(CommonDefines)</CommonDefines>
</PropertyGroup>
<ItemGroup>
<CustomAdditionalCompileInputs Include="$(SolutionDir)\_meta\definesFlags.txt" />
</ItemGroup>
</Project>
CustomAdditionalCompileInputs-items is taken as an input by Microsoft.Csharp.Core.targets.