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).
Related
I have created a wix sharp setup project and it works well. msi is created as desired.
Unfortunately, wix (sharp?) creates a folder called 'wix' in the project and places an autogenerated file in it. I really don't like that. Is there a way to avoid this modification of my source files?
It's possible to remove file again in csproj by adding the 'remove' line. I should however prefer not to have it soiling my source code, so I'm still looking for a better solution!
<ItemGroup>
...
<None Include="wix\$(ProjectName).g.wxs" />
<None Remove="wix\$(ProjectName).g.wxs" />
</ItemGroup>
<Reference Include="WixSharp, Version=1.11.0.0, Culture=neutral, PublicKeyToken=3775edd25acc43c2, processorArchitecture=MSIL">
<HintPath>..\packages\WixSharp.bin.1.11.0\lib\WixSharp.dll</HintPath>
</Reference>
<Reference Include="WixSharp.Msi, Version=1.11.0.0, Culture=neutral, PublicKeyToken=3775edd25acc43c2, processorArchitecture=MSIL">
<HintPath>..\packages\WixSharp.bin.1.11.0\lib\WixSharp.Msi.dll</HintPath>
</Reference>
<Reference Include="WixSharp.UI, Version=1.11.0.0, Culture=neutral, PublicKeyToken=3775edd25acc43c2, processorArchitecture=MSIL">
<HintPath>..\packages\WixSharp.bin.1.11.0\lib\WixSharp.UI.dll</HintPath>
</Reference>
BR, Anders
The answer (for me) was to use nuget wixsharp.bin instead of wixsharp as per (primary wixsharp developer) Oleg Shilo's response here:
https://github.com/oleg-shilo/wixsharp/issues/661
Oleg wrote (in case the link is lost in the malmstroem of the internet):
oleg-shilo commented [2019-08-11]
Yes it is possible. Instead of WixSharp NuGet package use
WixSharp.bin. It will not modify the project. Though then building the
project will simply compile the builder console application
{ProjectName}.exe. And you will need to execute this app from your
project post-build event.
The rest is the same.
I know I can reference an assembly depending on the project configuration, but can I do it based on the solution configuration? I'm thinking of something like this:
<ItemGroup Condition="'$(SolutionConfiguration)' == 'Debug1'>
<Reference Include="Library1">
<HintPath>C:\Path\To\Library1.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup Condition="'$(SolutionConfiguration)' == 'Debug2'>
<Reference Include="Library2">
<HintPath>C:\Path\To\Library2.dll</HintPath>
</Reference>
</ItemGroup>
If not like this, is there any other way I can reference one or another assembly depending on the solution configuration?
Solution configurations are linked to project configurations. For each solution configuration, we specifiy which project configurations to use. For example, when we select solution Release, projects Release are typically selected.
So create two project configurations matching the two solution configurations you want for the dll you want. When you select a solution configuration, different project configurations will be selected and the correct dll will de referenced.
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.
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.
I am attempting to debug this message:
The type 'Logging.LoggingProvider' is defined in an assembly that is not referenced. You must add a reference to assembly 'Logging.LoggingProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=71561dfc7a07d5da'.
I have several nuget packages that depend on each other in a chain. When digging into the project files that build these packages i have found that the way assemblies are being referenced is slightly different. Some have the key in them and others do not. this had led me to believe that if i find a way to make the references created by nuget consistent my problem will go away.
The assemblies were at one time signed. I thought the reference behaviour changed if i removed signed assemblies = false from the project, but that does not seem to be the case.
Eg in 1 solution i have used the same nuget package and version in 2 different projects the references are different
The incorrect one (or at least undesirable)
<Reference Include="Logging.LoggingProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=71561dfc7a07d5da, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\Logging.LoggingProvider.1.0.24\lib\Logging.LoggingProvider.dll</HintPath>
</Reference>
and in another project the correct one is
<Reference Include="Logging.LoggingProvider, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\Logging.LoggingProvider.1.0.24\lib\Logging.LoggingProvider.dll</HintPath>
</Reference>
What could be causing this? I am quite literally adding the nuget package to 1 project then the next.. One works and the other doesn't - I cant see anything in the project files explaining why.
NuGet uses the underlying VS layer to add references while installing a package.
What is the behavior when you try to add this reference to those projects manually ?