From this post:
You reference nuget Jetbrains.Annotations, and DO NOT define
JETBRAINS_ANNOTATIONS: Such annotations are useful only for developers
working with source code, they are not compiled in your binary
(Conditional statement is used) and they are not visible when
referencing your dll. You can even add developmentOnly="true"
attribute to Jetbrains.Annotations in packages.config, so by default
it would not be treated as dependency.
In my cproj file I have:
<Reference Include="JetBrains.Annotations, Version=10.2.1.0, Culture=neutral, PublicKeyToken=1010a0d8d6380325, processorArchitecture=MSIL">
<HintPath>..\..\Build Files\packages\JetBrains.Annotations.10.2.1\lib\net\JetBrains.Annotations.dll</HintPath>
<Private>True</Private>
</Reference>
Can I entirely get rid of this reference and rely on the packages.config entry:
<package id="JetBrains.Annotations" version="10.2.1" targetFramework="net45" developmentOnly="true" />
What is the purpose of including a reference in both the packages.config AND the cproj file, assuming that the cproj file already has a reference to packages.config?
The reference in the csproj file is used to indicate the hint path of .dll file. You need to specified the path when you calls the Class and Attributes from Jetbrains.Annotations library.
And the package.config file is managed by the NuGet infrastructure. It's used to track and restore the installed packages with their respective versions.
See here for some details about packages.config.
So they have different usage, you could not entirely get rid of this reference and only rely on the packages.config entry.
Related
I reference System.Net.Http as a nuget package in my project, the references are correct in packages.config and .csproj file, but in Visual Studio property tab it always uses the package in system's Reference Assembly path, does anybody know why?
Another weird thing is this file in built <webproj>\bin\roslyn has another version, seems it doesn't use the dll file neither in nuget nor in Reference Assembly.
And actually the System.Net.Http.dll in nuget package, in Reference Assembly, in built <webproj>\bin\roslyn directory are have different versions, the file in <webproj>\bin\roslyn seems use the file of Visual Studio directory(C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\Extensions\aqwf5fqp.2lv\System.Net.Http.dll or C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\system.net.http\4.3.0\runtimes\win\lib\net46\System.Net.Http.dll or C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\system.net.http\4.3.0\lib\net46\System.Net.Http.dll, judged by its version and file size)
dll in different path
assembly version
dll in nuget, package version 4.3.4
4.1.1.3
dll in Reference Assembly(aka referenced in VS property tab)
4.2.0.0
dll in built <webproj>\bin\roslyn directory
4.1.1.0
in packages.config
<package id="System.Net.Http" version="4.3.4" targetFramework="net472" />
in .csproj
<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\lib\Nugets\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
<Private>True</Private>
</Reference>
in property tab
And I want to force VS(property tab) or the file in bin\roslyn to use the dll in nuget package, how to do it please? Thank you.
You can try Migrate from packages.config to PackageReference.
This can help you Manage all project dependencies in one place: Just like project to project references and assembly references, NuGet package references (using the PackageReference node) are managed directly within project files rather than using a separate packages.config file.
What's the difference between referencing System in my .csprojfile and referencing System, System.Xml, and System.Xml.Linq?
Some backstory:
Using Visual Studio 2017 Community 15.4.4, I decided to upgrade the NuGet packages that my projects were using. Post-upgrade, I noticed that my packages.config and .csproj files now contain "extra" entries.
For example, previously my .csproj files contained (among other things) a simple line that stated:
<Reference Include="System" />,
but now, post upgrade, they also include the lines
<Reference Include="System.Xml" />
<Reference Include="System.Xml.Linq"/>
Likewise, my project.config files gained entries like:
<package id="System.Xml.Linq"... >
that previously did exist.
Creating a test solution, I wrote a small function that used a LINQ select statement, printed an enum that lives in System.Xml.Linq, and then manually removed the <Reference Include="System.Xml.Linq"/> in the .csproj file, and everything seemed to compile normally.
So why were these extra entries automatically added? Do they serve a purpose?
why were these extra entries automatically added? Do they serve a purpose?
Not sure why your packages.config files contain "extra" entry <package id="System.Xml.Linq"... >, may be error added or added as dependency for some packages (if you want to dig deeper into the reason for this issue, you should find out why this package added).
Generally, when you create a .NET framework project, the following .NET framework references would be added by default:
<Reference Include="System" />
<Reference Include="System.Xml.Linq"/>
Then you open the package System.Xml.Linq, you will find the this package only include a .NET framework 2.0 lib:
After install this package by nuget, the following lines will add into your project file:
<Reference Include="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\System.Xml.Linq.3.5.21022.801\lib\net20\System.Xml.Linq.dll</HintPath>
<Private>True</Private>
</Reference>
But if we install this package, above lines will replace the line <Reference Include="System.Xml.Linq"/>. Not sure why it not replace that line.
So that is the reason why you remove the reference to System.Xml.Linq in your .csproj file had no ill effects, Visual Studio still get the dll from the package.
I have a third party DLL which I need to reference in multiple c# projects in a solution.
It is presently referenced as follows.
<Reference Include="Contoso.App, Version=4.0.5.0, Culture=neutral, PublicKeyToken=xxxxxxxx, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\ThirdParty\Contoso\4.0.5.0\Contoso.App.dll</HintPath>
</Reference>
I have around 40 projects in my solution which reference the Contoso.App.Dll
Whenever the DLL version changes a new folder is created as follows
..\ThirdParty\Contoso\5.0\
I have to go and update all my 40 projects as follows.
<Reference Include="Contoso.App, Culture=neutral, PublicKeyToken=xxxxxxxx, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\ThirdParty\Contoso\5.0\Contoso.App.dll</HintPath>
</Reference>
Is there a better way to manage the version change of the DLL?
Can I create single variable in the solution and reuse it across all the projects?
Private NuGet repository is prefect, but requires too many changes. A simpler way is to create a common project and let other projects reference this common project.
common.props. It's better to use solution relative path instead of ...
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<Reference Include="Contoso.App, Culture=neutral, PublicKeyToken=xxxxxxxx, processorArchitecture=MSIL">
<HintPath>..\ThirdParty\Contoso\5.0\Contoso.App.dll</HintPath>
</Reference>
</ItemGroup>
</Project>
Import it in other project.
<Import Project="<MySolutionPath>\common.props"/>
There may be build errors in VS after changes are made in common.props because the reference is updated instantly. Verify it via command line msbuild.exe first.
Setup a Private Nuget Repository that the rest of your team can access.
See Scott's answer.
tl;dr
Open Visual Studios
Create a new Empty Web Project
Add the Nuget.Server Package
Package manager console: install-package nuget.server
Overwrite web.config: Yes
Open Web.config
Set appSettings
packagesPath: where the nuget is going to sit
Init:
nuget init c:\source c:\localnuget
Push:
nuget push {package file} -s http://localhost:51217/nuget {apikey}
Alternate hosting
Just to add flexibility to TriV's comment, you can define an environment variable (e.g. CONTOSO_VERSION) and use it in the pre-build event command to copy the DLL into your bin folder (or wherever you're referencing from) using $CONTOSO_VERSION. This way you can change the referenced DLL version back and forth via env variable. Make sure it's pre-build event for a project others depend on (or create a dummy project with others depending on it for a solution-wide pre-build event).
I'm trying to copy all metadata references from one project into another via Roslyn.
var updatedProject = destinationProject.AddMetadataReferences(sourceProject.MetadataReferences);
msWorkSpace.TryApplyChanges(updatedProject.Solution)
The references are copied without problems but the full path to the assembly is added into the project file:
<Reference Include="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2\System.Numerics.dll" />
Is there some option to add them via Roslyn (I don't want to manually edit csproj file) in this way?
<Reference Include="System.Numerics" />
This is just a bug. Please file the bug on GitHub.
I am trying to determine how a version number is determined for a nuget package.
I assumed that this would be in the packages.config file. In the packages.config file, this is the version number it is looking for: <package id="UnitClassLibrary" version="1.1.0" targetFramework="portable-net40+sl40+win+wp" /> Likewise, in the .csproj file, it is looking for <Reference Include="UnitClassLibrary, Version=1.1.0, Culture=neutral, processorArchitecture=MSIL">.
So I have defined a need for version 1.1.0 in both of these files. However, when I try to run a nuget restore command, it reports Unable to find version '1.10' of package 'UnitClassLibrary'. I cannot find anywhere that the nuget version is defined as 1.10.