I'm trying to build the application that uses libzip.
I build the libzip library first and got zip.lib and zip.dll.
Now on the linking stage I get an error
Error LNK1104 cannot open file 'zip.lib'
It seems that AdditionalLibraryDirectories is ignores whereas AdditionalIncludeDirectories works well (all zip-related headers are found)
settings.props:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets" />
<PropertyGroup Label="UserMacros" />
<PropertyGroup />
<ItemDefinitionGroup>
<ClCompile>
<AdditionalIncludeDirectories>$(SolutionDir)\libzip\lib;$(SolutionDir)\libzip\build;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
</ClCompile>
<Link>
<AdditionalLibraryDirectories>$(SolutionDir)\libzip\build\lib\Debug</AdditionalLibraryDirectories>
<AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;odbccp32.lib;zip.lib;%(AdditionalDependencies)</AdditionalDependencies>
</Link>
</ItemDefinitionGroup>
<ItemGroup />
</Project>
If I add "$(SolutionDir)\libzip\build\lib\Debug\" to Additional library directories of the project, everything works! So the zip library is not corrupted.
Related
I have to set "C++ Language standard" to "C++ 20" and "multi-processor compilation" to yes every time I open a new project.
Is there any way to keep the setting? Thanks.
You could create prop file. For your reference:Share or reuse Visual Studio project settings
I think you could do this by customizing project templates. See Customize project and item templates for details.
E.g. if you edit project.vcxproj file in %DevEnvInstallDir%\ProjectTemplates\VC\WindowsDesktop\ directory and add ItemDefinitionGroup section with LanguageStandard setting as shown below, then new C++ projects will have this section in *.vcxproj files. Probably you'd better not directly change the preinstalled templates, but to make copies of the required one(s) and customize them instead. Also there might be a more accurate place to put this setting, please do some research.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup Label="ProjectConfigurations">
$projectconfigurations$
</ItemGroup>
<PropertyGroup Label="Globals">
<VCProjectVersion>16.0</VCProjectVersion>
<Keyword>$keyword$</Keyword>
<ProjectGuid>{$guid1$}</ProjectGuid>
<RootNamespace>$rootnamespace$</RootNamespace>
<WindowsTargetPlatformVersion>$windowstargetplatformversion$</WindowsTargetPlatformVersion>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
$labeledpropertygroups$
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ImportGroup Label="ExtensionSettings">
</ImportGroup>
<ImportGroup Label="Shared" >
</ImportGroup>
$propertysheets$
<PropertyGroup Label="UserMacros" />
$propertygroups$
$itemdefinitiongroups$
<ItemDefinitionGroup>
<ClCompile>
<LanguageStandard>stdcpp20</LanguageStandard>
</ClCompile>
</ItemDefinitionGroup>
<ItemGroup></ItemGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
</Project>
I am trying to setup a default location for OutDir and IntDir to be used by all projects in the solution. Such as: <OutDir>$(SolutionDir)bld\$(Platform)\$(ProjectName)\$(Configuration)\</OutDir>
When I set this in the Directory.Build.props file, it looks okay in Visual Studio Properties dialog; but when I build, the $(ProjectName) portion is empty. This tells me that this macro was not available when OutDir was read in Directory.Build.props.
I tried adding this to the Directory.Build.targets file and it appeared to be ignored altogether.
Another goal is to not modify any of the vcxproj files after this initial change. And new projects would inherit these settings automatically.
Is this possible? Perhaps I am placing the setting in the wrong place/order in the file... ?
This is a snippet of the Directory.Build.props:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets">
</ImportGroup>
<!-- Define macros for easy and consistent access to various parts of the tree -->
<PropertyGroup Label="UserMacros">
<GslInclude>$(SolutionDir)packages\Microsoft.Gsl.0.1.2.1\build\native\include</GslInclude>
<mySrcDir>$(SolutionDir)src\</mySrcDir>
<myBldDir>$(SolutionDir)bld\</myBldDir>
<myBldIntDir>$(SolutionDir)bld_int\</myBldIntDir>
</PropertyGroup>
<ItemDefinitionGroup />
<ItemGroup>
<BuildMacro Include="GslInclude"> <Value>$(GslInclude)</Value> </BuildMacro>
<BuildMacro Include="mySrcDir"> <Value>$(mySrcDir)</Value> </BuildMacro>
<BuildMacro Include="myBldDir"> <Value>$(myBldDir)</Value> </BuildMacro>
<BuildMacro Include="myBldIntDir"> <Value>$(myBldIntDir)</Value> </BuildMacro>
</ItemGroup>
<!-- Platform Toolset, Windows SDK -->
<PropertyGroup Label="Globals">
<WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
</PropertyGroup>
<!-- Default Compiler settings -->
<ItemDefinitionGroup>
<ClCompile>
<!-- .... -->
</ClCompile>
</ItemDefinitionGroup>
<!-- Default Folders for target output -->
<PropertyGroup>
<OutDir>$(myBldDir)$(Platform)\$(ProjectName)\$(Configuration)\</OutDir>
<IntDir>$(myBldIntDir)$(Platform)\$(ProjectName)\$(Configuration)\</IntDir>
</PropertyGroup>
</Project>
And then of course, I simply remove all <OutDir> and <IntDir> settings in the proj files.
I would also love to be able to place conditions on settings based on the version of Visual Studio. Some of our developers are using VS2017 with older ToolSet; some are using VS2019 with the latest....
Thanks to those who helped with this. I got it working - at least for my main goal of establishing a pre-defined location for build 'output'.
Referencing information from here: https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2019 and searching around in the VS props files, I find a macro 'MSBuildProjectName' which is set early in the process.
I created a Directory.Build.props file in the root of my build tree with contents like this:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets">
</ImportGroup>
<!-- Define macros for easy and consistent access to various parts of the tree -->
<PropertyGroup Label="UserMacros">
<GslInclude>$(SolutionDir)packages\Microsoft.Gsl.0.1.2.1\build\native\include</GslInclude>
<myBldDir>$(SolutionDir)bld\</myBldDir>
<myBldIntDir>$(SolutionDir)bld_int\</myBldIntDir>
</PropertyGroup>
<ItemDefinitionGroup />
<ItemGroup>
<BuildMacro Include="GslInclude"> <Value>$(GslInclude)</Value> </BuildMacro>
<BuildMacro Include="myBldDir"> <Value>$(myBldDir)</Value> </BuildMacro>
<BuildMacro Include="myBldIntDir"> <Value>$(myBldIntDir)</Value> </BuildMacro>
</BuildMacro>
<!-- etc .... -->
</ItemGroup>
<!-- Platform Toolset, Windows SDK -->
<PropertyGroup Label="Globals">
<WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
</PropertyGroup>
<PropertyGroup Label="Configuration">
<PlatformToolset>v142</PlatformToolset>
</PropertyGroup>
<PropertyGroup>
<IntDir>$(myBldIntDir)$(Platform)\$(MSBuildProjectName)\$(Configuration)\</IntDir>
<OutDir>$(myBldDir)$(Platform)\$(MSBuildProjectName)\$(Configuration)\</OutDir>
</PropertyGroup>
<!-- lots more .... -->
</Project>
Settings in this file affect all projects living 'below' it in the folder structure.
If a sub-folder needs a different value, add a Directory.Build.props to that folder which imports the 'parent' props file (it may be several layers above):
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)../'))" />
<ImportGroup Label="PropertySheets">
</ImportGroup>
<PropertyGroup>
<IntDir>$(myBldIntDir)$(Platform)\Tests\$(MSBuildProjectName)\$(Configuration)\</IntDir>
<OutDir>$(myBldDir)$(Platform)\Tests\$(MSBuildProjectName)\$(Configuration)\</OutDir>
</PropertyGroup>
</Project>
Settings in the 'child' props file override anything set in its parents.
Once I removed all <OutDir> and <IntDir> elements in the XML project files, the "Output Directory" and "Intermediate Directory" settings show up in regular font (not bold which indicates it is not inheriting) and, of course, when I build, everything goes to the consolidated folder tree; away from the source. And the cool thing: New projects will be populated automatically with these new default settings.
note: #dxiv points out that some settings may be pickier and require more work.
It is possible, and it is in fact the recommended way to share settings between projects. Only caveat is that the scheme is rather sensitive to the section tags and order/placement of inclusions. The following should work for OutDir and IntDir.
Directory.Build.props
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<_PropertySheetDisplayName>Directory.Build</_PropertySheetDisplayName>
</PropertyGroup>
<ImportGroup Label="PropertySheets" />
<PropertyGroup Label="UserMacros">
<!-- other user macros -->
<OutDir> ... </OutDir>
<IntDir> ... </IntDir>
</PropertyGroup>
<!-- rest of .props file --->
Project.vcxproj
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- ... -->
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<!-- include custom .props here, can also use full or relative path -->
<ImportGroup Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="Directory.Build.props" />
</ImportGroup>
<!-- ... -->
I am upgrading some big solution files (80 projects) from Visual Studio 2010 to Visual Studio 2017. I allowed VS to upgrade the solution and project files (they are all VC++ projects).
If you go to the "Linker" settings for the project, they are all set to generate an intermediate manifest.
I am running VS2017 as Administrator, and for each of the projects I try to build, I get an error similar to:
LINK : fatal error LNK1104: cannot open file 'D:...\intel_win32_Debug\bundle_creator\bundle_creator.exe.intermediate.manifest'
This works fine building the projects in VS2010. In VS 2010, the intermediate manifest is produced and feeds the manifest tool, and the projects build. The output directory exists and has intermediate .obj files, as well as a .pdb file. I also checked the directory privileges and ownership, and they appear to be in order.
This error happens for both debug/release builds.
Does anyone know why this would work in 2010 but not in 2017?
EDIT: There is NO content in the linker trace log files. (Whereas plenty when done in VS2017). Here is a sample project file.
EDIT 2: One huge difference I see is that in the VS2010 case I see trace logs for the mt.ext manifest tool, whereas in 2017 I don't. So it appears like the manifest tool isn't running for some reason. The manifest settings haven't changed - is there some setting in VS2017 for running the manifest tool before the linker?
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Debug|Win32">
<Configuration>Debug</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|Win32">
<Configuration>Release</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Template|Win32">
<Configuration>Template</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>{FAA8F144-2DE8-4397-B694-FDA2BF43E610}</ProjectGuid>
<RootNamespace>bundle_creator</RootNamespace>
<SccProjectName>
</SccProjectName>
<SccAuxPath>
</SccAuxPath>
<SccLocalPath>
</SccLocalPath>
<SccProvider>
</SccProvider>
<WindowsTargetPlatformVersion>10.0.16299.0</WindowsTargetPlatformVersion>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<UseOfMfc>false</UseOfMfc>
<PlatformToolset>v141</PlatformToolset>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<UseOfMfc>false</UseOfMfc>
<PlatformToolset>v141</PlatformToolset>
</PropertyGroup>
<PropertyGroup Label="Configuration" Condition="'$(Configuration)|$(Platform)'=='Template|Win32'">
<PlatformToolset>v141</PlatformToolset>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ImportGroup Label="ExtensionSettings">
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="..\..\..\..\..\build\properties\release.props" />
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="..\..\..\..\..\build\properties\debug.props" />
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<_ProjectFileVersion>10.0.30319.1</_ProjectFileVersion>
</PropertyGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<ClCompile>
<AdditionalIncludeDirectories>$(CORE_LIBRARIES_DIR)\3rdParty\zlib\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
<PreprocessorDefinitions>CONSOLE_MODE;OMIT_CRYPTO_SUPPORT=t;OMIT_SYSTEM_VALUES=t;_CONSOLE;__BUILD_STATIC_APPLICATION__;%(PreprocessorDefinitions)</PreprocessorDefinitions>
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>CONSOLE_MODE;OMIT_CRYPTO_SUPPORT=t;OMIT_SYSTEM_VALUES=t;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
</ResourceCompile>
<Link>
<AdditionalDependencies>zlib.lib;%(AdditionalDependencies)</AdditionalDependencies>
<AdditionalLibraryDirectories>$(CORE_LIBRARIES_DIR)\3rdparty\zlib\lib;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<SubSystem>Console</SubSystem>
</Link>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<ClCompile>
<AdditionalIncludeDirectories>$(CORE_LIBRARIES_DIR)\3rdparty\zlib\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
<PreprocessorDefinitions>CONSOLE_MODE;OMIT_CRYPTO_SUPPORT=t;OMIT_SYSTEM_VALUES=t;_CONSOLE;__BUILD_STATIC_APPLICATION__;%(PreprocessorDefinitions)</PreprocessorDefinitions>
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>CONSOLE_MODE;OMIT_CRYPTO_SUPPORT=t;OMIT_SYSTEM_VALUES=t;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
</ResourceCompile>
<Link>
<AdditionalDependencies>zlib.lib;%(AdditionalDependencies)</AdditionalDependencies>
<AdditionalLibraryDirectories>$(CORE_LIBRARIES_DIR)\3rdparty\zlib\lib;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<SubSystem>Console</SubSystem>
</Link>
</ItemDefinitionGroup>
<ItemGroup>
<ClCompile Include="bundle_creator.cpp" />
<ClCompile Include="common_bundle.cpp" />
</ItemGroup>
<ItemGroup>
<ResourceCompile Include="bundler_version.rc" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\..\..\..\..\libraries\core\library\basis\basis.vcxproj">
<Project>{571b0731-ed86-476a-a723-9ecf75cb0d51}</Project>
</ProjectReference>
<ProjectReference Include="..\..\..\build_prerequisites.csproj">
<Project>{28ba1c03-7e39-4ce2-993f-72a7772fa758}</Project>
</ProjectReference>
</ItemGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
<ProjectExtensions>
<VisualStudio>
<UserProperties RESOURCE_FILE="bundler_version.rc" />
</VisualStudio>
</ProjectExtensions>
</Project>
And here is the debug property sheet
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Label="UserMacros">
<REPOSITORY_DIR Condition="'$(REPOSITORY_DIR)'==''">$(SolutionDir)</REPOSITORY_DIR>
<BUILDER_DIR>$(REPOSITORY_DIR)\..\..\build\</BUILDER_DIR>
<BUILD_TOP>$(REPOSITORY_DIR)\..\..\</BUILD_TOP>
<LIBRARIES_DIR>$(REPOSITORY_DIR)\..\..\libraries\</LIBRARIES_DIR>
<CORE_LIBRARIES_DIR>$(REPOSITORY_DIR)\..\..\libraries\core\</CORE_LIBRARIES_DIR>
<SHARED_LIBRARIES_DIR>$(REPOSITORY_DIR)\..\..\libraries\shared\</SHARED_LIBRARIES_DIR>
</PropertyGroup>
<PropertyGroup>
<_ProjectFileVersion>10.0.30319.1</_ProjectFileVersion>
<OutDir>$(REPOSITORY_DIR)\binaries\</OutDir>
</PropertyGroup>
<ImportGroup Label="PropertySheets">
<Import Project="$(BUILDER_DIR)\properties\vcoptions.props" />
</ImportGroup>
<ItemDefinitionGroup>
<Midl>
<PreprocessorDefinitions>DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
</Midl>
<ClCompile>
<Optimization>Disabled</Optimization>
<InlineFunctionExpansion>OnlyExplicitInline</InlineFunctionExpansion>
<WholeProgramOptimization>false</WholeProgramOptimization>
<PreprocessorDefinitions>_DEBUG;DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MinimalRebuild>false</MinimalRebuild>
<StringPooling>false</StringPooling>
<FunctionLevelLinking>false</FunctionLevelLinking>
<RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
</ResourceCompile>
<Manifest>
<AdditionalManifestFiles>$(IntDir)$(TargetFileName).intermediate.manifest;$(BUILDER_DIR)\properties\security_manifest.txt;%(AdditionalManifestFiles)</AdditionalManifestFiles>
</Manifest>
<Link>
<AdditionalLibraryDirectories>$(REPOSITORY_DIR)\binaries;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<ProgramDatabaseFile>$(REPOSITORY_DIR)\binaries\$(TargetName).pdb</ProgramDatabaseFile>
<ImportLibrary>$(REPOSITORY_DIR)\binaries\$(ProjectName).lib</ImportLibrary>
<AdditionalDependencies>msvcrtd.lib;%(AdditionalDependencies)</AdditionalDependencies>
<IgnoreSpecificDefaultLibraries>msvcrt.lib;mfc.lib</IgnoreSpecificDefaultLibraries>
</Link>
</ItemDefinitionGroup>
</Project>
I have a netstandard project which includes two project references. Visual studio 2017 is being used to build the nukpg. When the project is built the produced nupkg only contains the assembly produced by that project and lists the two project references as nuget dependencies. Is there a way to force the packaging to include those assemblies as lib files?
csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net462</TargetFramework>
<RootNamespace>Verifier.Observations.DevOps.Health</RootNamespace>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<VersionPrefix>1.0.1</VersionPrefix>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\Verifier.Observations.Aspects\Verifier.Observations.Aspects.csproj" />
<ProjectReference Include="..\Verifier.Observations\Verifier.Observations.csproj" />
</ItemGroup>
<ItemGroup>
<Reference Include="System.ComponentModel.Composition"/>
<Reference Include="System.Net.Http" />
</ItemGroup>
</Project>
Update
Based upon feedback from #alexgiondea-msft the package is now created as desired using the following
csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<VersionPrefix>1.0.1</VersionPrefix>
<TargetFramework>net462</TargetFramework>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<NuspecFile>Verifier.Observations.DevOps.Health.Nuspec</NuspecFile>
<NuspecProperties>version=$(VersionPrefix);id=$(MSBuildProjectName);author=$(Authors);copy=$(Copyright);iconUrl=$(PackageIconUrl)</NuspecProperties>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\Verifier.Observations.Aspects\Verifier.Observations.Aspects.csproj" />
<ProjectReference Include="..\Verifier.Observations\Verifier.Observations.csproj" />
</ItemGroup>
<ItemGroup>
<Reference Include="System.ComponentModel.Composition" />
<Reference Include="System.Net.Http" />
</ItemGroup>
</Project>
nuspec
<package >
<metadata>
<id>$id$</id>
<version>$version$</version>
<title>$title$</title>
<authors>$author$</authors>
<owners>$author$</owners>
<iconUrl>$iconUrl$</iconUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Inspect automation service to ensure it is up and operational</description>
<releaseNotes></releaseNotes>
<copyright>$copy$</copyright>
<tags>verifier-observation-plugin automation</tags>
<dependencies>
<group targetFramework="net462" />
</dependencies>
<references>
<group targetFramework="net462">
<reference file="Verifier.Observations.DevOps.Automation.dll" />
</group>
</references>
</metadata>
<files>
<file src="bin\*\net462\*.dll" target="lib\net462" />
<file src="bin\*\net462\*.pdb" target="lib\net462" />
</files>
</package>
You can control where assemblies are deployed in the nuget package using an item in an itemgroup, similar to this:
<ItemGroup>
<None Include="!!path_to_assembly!!">
<PackagePath>lib\net462</PackagePath>
<Pack>true</Pack>
<Visible>false</Visible>
</None>
</ItemGroup>
That should include the specified assembly in the package.
You can add the following target to your .csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard2.0;net47</TargetFrameworks>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);CopyProjectReferencesToPackage</TargetsForTfmSpecificBuildOutput>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\ClassLibrary2\ClassLibrary2.csproj" PrivateAssets="all" />
<ProjectReference Include="..\ClassLibrary3\ClassLibrary3.csproj" Condition="'$(TargetFramework)' == 'net47'" PrivateAssets="all" />
</ItemGroup>
<Target Name="CopyProjectReferencesToPackage" DependsOnTargets="ResolveReferences">
<ItemGroup>
<BuildOutputInPackage Include="#(ReferenceCopyLocalPaths->WithMetadataValue('ReferenceSourceTarget', 'ProjectReference'))" />
</ItemGroup>
</Target>
</Project>
Source 1
Source 2
Reference: Advanced extension points to create customized package
I am trying to understand the visual cpp project document here (https://learn.microsoft.com/en-us/cpp/build/walkthrough-using-msbuild-to-create-a-visual-cpp-project).
<Project DefaultTargets="Build" ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<ProjectConfiguration Include="Debug|Win32">
<Configuration>Debug</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|Win32">
<Configuration>Release</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
</ItemGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.default.props" />
<PropertyGroup>
<ConfigurationType>Application</ConfigurationType>
<PlatformToolset>v120</PlatformToolset>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ItemGroup>
<ClCompile Include="main.cpp" />
</ItemGroup>
<ItemGroup>
<ClInclude Include="main.h" />
</ItemGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Targets" />
</Project>
I gather that ClCompile, is an item as it is nested under the ItemGroup tag, it also seems that the files to be compiled are referred to in the ClCompile tag. On the documentation page for Items, https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-items, it states that Items are inputs into the build system. I dont see a task above which takes these ClCompile items and compiles them, how is compilation being achieved? Is the ClCompile item as task as well?
I dont see a task above which takes these ClCompile items and compiles them, how is compilation being achieved? Is the ClCompile item as task as well?
After search all the .targets and .props files in the VCTargets folder under following path:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets
We could find following code snippet in the Microsoft.CppCommon.targets file:
<Target Name="ClCompile"
Condition="'#(ClCompile)' != ''"
DependsOnTargets="SelectClCompile">
<PropertyGroup>
<CLToolArchitecture Condition="'$(CLToolArchitecture)' == ''">$(VCToolArchitecture)</CLToolArchitecture>
<CLDeleteOutputOnExecute Condition="'$(CLDeleteOutputOnExecute)' == ''">true</CLDeleteOutputOnExecute>
</PropertyGroup>
<ItemGroup>
<ClNoDependencies Condition="'#(ClNoDependencies)' == '' and '%(ClInclude.NoDependency)' == 'true'" Include="#(ClInclude)"/>
<ClNoDependencies Condition="'$(NoDependencies)' != ''" Include="$(NoDependencies)" />
</ItemGroup>
...
<OnError Condition="'$(OnXamlPreCompileErrorTarget)' != ''" ExecuteTargets="$(OnXamlPreCompileErrorTarget)" />
</Target>
So ClCompile should be a target, which is used to execute the Visual C++ compiler tool, cl.exe to compile the C/C++ source file. That is reason why it not in the MSBuild-item.
See MSBuild (Visual C++) Overview for some more details.
Yes, CLCompile actually runs the CLTask task class. I suspect (though don't know for sure) they did it that way so they could have both CLCompile and CLInclude without having to write task implementations for each. I am not sure what namespace that is found in or the assembly, unlike tasks for pure .net languages the c++ tasks are not in the .net library docs.