Let's say I have some NuGet package that contains c++ dll and interop for this dll. When I install this package, I see that my scproj file gets updated with the following reference:
<Reference Include="Interop.MyCppAssembly, Version=1.1.1.1, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\packages\MyNuGetPackage.1.1.1.1\lib\Interop.MyCppAssembly.dll</HintPath>
<Private>False</Private>
<EmbedInteropTypes>False</EmbedInteropTypes>
</Reference>
You can see that HintPath points to the folder where my packages are installed. You can also see that I set Copy Local to false so Interop.MyCppAssembly.dll won't be copied to my output directory (let's call it bin) during the build. I did it intentionally, because I don't want to put any third party dlls into my bin folder to avoid mess in my output directory. Instead, I would like to create a subfolder in my bin
like bin\ThirdPartyLibs and put all third party dlls there.
But how can I do this? I know I can set CopyLocal to true, and then use Post Build Event to move Interop.MyCppAssembly.dll from bin to bin\ThirdPartyLibs but I don't like this. Is there any other solution how to copy dll to the subfolder of the output directory during the build?
Related
There is an error System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Management, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.'.I figured when the System.Management.dll is in the output directory, the error will be gone.
It is reference using NuGet but I couldn't get libraries in NuGet to be copied to the output folder. So I thought of adding the physical System.Management.dll file into my project and and reference it as assemblies (right-click project -> Add Reference -> browse to library) thenset 'Copy Local' to True. However, the dll still won't get copied over to the output folder.
The application is on .Net 6. Is there a reason behind why I can't copy this library like other?
A .NET6 project would normally use System.Management version 6.0.0.
The error suggests that there is another package in your project that explicitly depends on 4.0.0.
Without knowing the specifics of you projects, I suggest:
inspecting the build output for warnings about package version,
upgrading 3rd party packages in your solution.
Figured out I could copy nuget package references to output directory by setting this attribute in the project file
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Then the nuget referenced packages will be copied to the output directory.
I have .NET452 project - lets call it Consumer.csproj that I want to consume nuget lets call it SharedTargets that contained some custom targets files (SharedTargets.targets) from msbuild.
I'm using PackageReference format and now (compared to what it used to be) nuget packages are being restored to shared folder (%userprofile%.nuget\packages), and I'm not sure if it is good idea to reference it via that (doesn't feel right).
Eg:
<PackageReference Include="SharedTargets">
<Version>1.0</Version>
</PackageReference>
<Import
Project="$(USERPROFILE)\.nuget\packages\SharedTargets\1.0\SharedTargets.targets"
/>
Also this works only in VS, running this from command line (msbuild) I'm getting chicken-egg problem:
Confirm that the path in the <Import> declaration is correct, and that
the file exists on disk.
Obviously since I need to restore nuget first before I can use it :)
So question:
is there some more elegant way how to resolve path to the nuget package inside project file
is there a way how to make msbuild succeed (i.e. restore packages before SharedTargets.target is imported)
You shouldn't try to manually import targets distributed via NuGet.
Put your .targets file inside a build subfolder inside the package and name it SharedTargets.targets (package id + .targets) and NuGet will automatically include the targets - for packages.config projects it will modify the project file on install and for PackageReference projects the targets will be imported by modifying an implicitly generated targets file in the obj\ directory.
I am trying to ensure that the .dll.config file generated in a reference project is pulled into the parent project's /bin directory during a build. I've read here and here about using the AllowedReferenceReleatedFileExtension setting in the parent project's .vbproj file, but I'm getting a warning:
The element 'PropertyGroup' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003' has invalid child element 'AllowedReferenceRelatedFileExtensions' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003'
the property group I added to the end of the .vbproj file looks like this:
<PropertyGroup>
<AllowedReferenceRelatedFileExtensions>
.pdb
.xml
.dll.config
</AllowedReferenceRelatedFileExtensions>
</PropertyGroup>
I'm a little out of my depth with .net builds, so I'm not sure where to start trying to resolve this warning. There are a few other similar warnings in the .vbproj file that don't seem to be causing any problems, but running the build after I added this section didn't actually copy the reference project's .dll.config file over.
Any ideas?
According to this answer (which worked for me), it seems you need to add a semi colon after each extension.
Not sure if that is mandatory
Set the build output verbosity to Detailed and see where the dependencies are being copied from. It is possible that your target dll is referenced indirectly from multiple projects and it is being copied from the project that does not have the AllowedReferenceRelatedFileExtensions set.
In the build output search for:
Dependency "your target dll"
Resolved file path is "path where the target dll is being copied from"
P.S.: "Target dll" means the dll whose .dll.config is required to be copied to the referencing project's output folder.
Did you try to use MSBuild instead of add tags manually?
MSBuild.exe MyProject.csproj /t:build "/p:AllowedReferenceRelatedFileExtensions=.pdb;.xml;.dll.config"
Recent libgit2sharp Nuget uses a new Nuget feature that allows you to include a piece of a build script in your NuGet. The purpose it to copy a native dll to a subfolder of the bin folder, like that:
<ItemGroup>
<None Include="$(MSBuildThisFileDirectory)\..\..\lib\net40\NativeBinaries\amd64\git2-e0902fb.dll">
<Link>NativeBinaries\amd64\git2-e0902fb.dll</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>...
Now, it was all nice and beautiful locally, but when I deployed it to AppHarbor, the native dlls appeared in the /bin folder (in addition to the target subfolder), which caused my app to fail.
The problem lies in the _CopyWebApplicationLegacy target, which does not execute locally (it's run only if you have a non-default output dir), thus I don't have this problem on my dev machine. Namely, it executes the following piece of code:
<!-- Copy items that have been marked to be copied to the bin folder -->
<Copy SourceFiles="#(_SourceItemsToCopyToOutputDirectory)"
DestinationFolder="$(WebProjectOutputDir)\bin"
SkipUnchangedFiles="true"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"/>
You can see that the target folder is always /bin -- I believe it's a bug in the Microsoft.WebApplication.targets file (I can't control it on the target machine).
Is there a simple fix, or should I revert to a script in the PostBuild event (which I'll have to update with each new version)?
As mentioned here: https://github.com/libgit2/libgit2sharp/issues/1089#issuecomment-111000722
the way AppHarbor is building your project, it's triggering the old _CopyWebApplicationLegacy target, and that is basically broken. It messes up all files that are using the Copy to Output Directory property by putting them directly into the output directory instead of respecting the relative folder structure. It also doesn't run any web.config transforms you may have.
You can make your project use the newer _CopyWebApplication target instead by adding the following to your project file:
<UseWPP_CopyWebApplication>True</UseWPP_CopyWebApplication>
<PipelineDependsOnBuild>False</PipelineDependsOnBuild>
The thing I'm not sure about is if AppHarbor has some reason why they wouldn't want you to use the newer copy target instead of the old broken one.
Attempting to build a C# project which has numerous references to assemblies in NuGet packages fails in TeamCity but works fine in Visual Studio.
Found in the log;
For SearchPath "{HintPathFromItem}".
[13:48:15][ResolveAssemblyReference]
Considered "..\packages\AspNetMvc.4.0.20126.16343\lib\net40\System.Web.Mvc.dll", but it didn't exist.
The reference in the project file is;
<Reference Include="System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\packages\AspNetMvc.4.0.20126.16343\lib\net40\System.Web.Mvc.dll</HintPath>
</Reference>
Any ideas? It seems like it's not starting from the correct directory so can't resolve "../packages" which exists one level above the .csproj file.
I know this has been answered, but maybe someone else has had the same problem I did.
My hint paths in my project file were incorrectly pointing to packages and changing it to ..packages fixed it for me.
So changing it from this:
<Reference Include="Newtonsoft.Json">
<HintPath>packages\Newtonsoft.Json.5.0.5\lib\net40\Newtonsoft.Json.dll</HintPath>
</Reference>
To this:
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.5\lib\net40\Newtonsoft.Json.dll</HintPath>
</Reference>
Fixed it.
I had restructured my projects since installing the NuGet packages so even though '../packages' was correct for the main project, it wasn't for the other projects which had been moved.
Uninstalling and re-installing the NuGet packages writes the paths correctly or more straightforward, doing a find and replace on the paths in each .csproj file.
My understanding at this point is based on the information here: http://youtrack.jetbrains.com/issue/TW-20525
But I am just diving into both TeamCity and NuGet at the same time (coming from CruiseControl.NET)
So what I did for the time being is to add a "NuGet Installer" build step before my vs.net solution build step and everything worked great.
You either need to add the packages directory to source control or enable nuget to automatically download packages (its a feature in the right click menu of nuget 1.6)
See http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
Sorry for resurrecting this old post, but in addition to the above excellent points (Tjaart, SeeNoWeevil, Luke), you might also want to check the property CopyLocal=true for the references that you nuget'ed down.
For myself, this has often been the one tiny oversight that leads to exactly the error that the OP was mentioning.
You can highlight the file in Solution Explorer and got to Properties, and verify that Copy to Output Directory is set to True
Ensure that the .dll and .pdb files are included in source control (or have been downloaded).
For TFS (not TeamCity), by default, .pdb files and .dll files are excluded. So double-check that all files for each package sub-directory have been included, not just the nuget .xml file.
Background: I came to this question with the same thought as some other posters - that the relative reference in the .csproj file might be incorrect. After using a path in the .csproj file to ensure that the reference was absolute with regards to the project...
<HintPath>$(MSBuildProjectDirectory)\..\.nuget\packages\Common.Logging.Core.3.0.0\lib\net40\Common.Logging.Core.dll</HintPath>
..only to get the same error, I double-checked that the required files existed. I also did an MSBuild build on my local machine (as opposed to Visual Studio build), and it worked. Further investigation on the build server revealed that the specified files did not exist, even though the directory, and .nuget package .xml files did.