I have a nuspec file that builds a nuget-package. I would like to control the dependencies, where I allow a range of versions, but what to always install a spesific version.
Basically this (not valid syntax):
<dependency id="Microsoft.CrmSdk.CoreAssemblies" version="8.2.0.2" allowedVersions="6.0.0" />
I want the nuget to dependency to accept 6 or higer (up to 9), but always want it to install 8.2.0.2 as default.
If I had version="6.0.0", it would always install the 6 version?
Any tips?
It is possible to specify an accepted version range in a nuspec-file with a version-range syntax. Accepting every version with a major version between 6 and (including) 9 would be specified by [6.0.0, 10.0.0).
What I understand from your question is that you want to specify an accepted version range but you want to force a certain version to be installed. There is no way I know of to achieve this but I also don't see the requirement for it: By specifying an accepted version range, the nuspec-file specifies to which versions of the dependency packages this package is compatible with. Hence, all accepted versions should work.
Forcing a certain version to be installed contradicts this compatibility statement in my opinion. This sounds as if you want to achieve a different goal: To verify that a consistent version of a NuGet package is installed in an application. This, however, should be solved on the consuming side, i.e. the solution that installs the NuGet packages. Assume the nuspec-file defines a package A that accepts all versions [6.0.0, 10.0.0) from Microsoft.CrmSdk.CoreAssemblies, but the consuming solution should always use version 8.2.0.2. Then this version 8.2.0.2 should be installed there first and afterwards the current version of package A can be installed, finding its dependency to Microsoft.CrmSdk.CoreAssemblies already resolved.
To achieve a consistent consuming solution, we implement checks on the CI server that verify that every package is referenced in all projects in exactly one version. By this we get a consistent product while keeping the actual NuGet packages flexible to be used with a different version of dependency packages in other products.
Related
I am very new to embedded Linux and am working with buildroot. We have a DNP3 library that is very old and would like to upgrade from 2.3 to 3.1. I do not know where to even start.
Can someone point me to a tutorial or instructions on how to upgrade an existing library or package?
It's not explained explicitly in the Buildroot manual, but updating a package is:
finding the package directory (e.g. package/dnp3);
change the version number in the dnp3.mk file;
download the package with make dnp3-source;
this will give an error because of a missing hash: note the hash and update it in dnp3.hash.
Of course, often that is not enough because the updated package has new dependencies, or it has to be patched to be able to build it in cross-compilation, or various other issues.
I am considering upgrading go-github from v17.0.0+incompatible to v28
I notice some versions that go-github released has a +incompatible suffix, especially for the v1 category. What does that entail? I am guessing version with +incompatible are incompatible with the newer/older version?
In general, when updating a third party dependency, how can I know if upgrading to the newer version is safe? Do I just have to read through the change logs?
Go in general does not want you to use the same import path for multiple incompatible versions of a project. This is so that one dependency can use one major version of a module and another dependency can use another.
This syntax indicates that the repository is not using a suffix for their module paths for a non-v0, non-v1 version, and bypasses the logic in the module code that does semantic import versioning. The documentation about this functionality is available on the Go website.
Since going from one major version to another is a breaking change in semantic versioning, you'll need to determine out of band whether or not they're compatible. The +incompatible suffix doesn't implicitly denote this, but going from v17 to v28 does. So changelogs might be a good idea, or you could just update and run your tests if you're confident in your testsuite.
Is there a way to install multiple versions of the same package in CentOS/RHEL (7/8) if the package installs separate files in each version?
We have an application we've recently converted to using RPM instead of a home-built package manager based on tar. In order to make atomic-like switches between versions, each version installed in separate directories with the version number in the name, and a symlink with the unversioned name pointed to the current, or previous, version at any given moment in time. The application, of course, used the unversioned name to get init script, configuration files, interpreter version and code. I'm thinking that the alternatives package would be the basis for this, although we wouldn't use the alternatives command to manage symlinks (although there's no technical reason not to).
Not exactly as you describe.
Some packages allow this (Kernel and Kernel-devel being two of them) but i beilieve this is an exception added within the package manager.
Certain Applications like PHP and Python which is perfectly acceptable to have multiple version (Python2.X and 3.X) do this by changing the base name of the application/rpm.
Take a look at: https://rpm.org/user_doc/multiple_versions.html
It gives a good insight on how to achieve what you want
Is it possible to use Cake to always get the latest version of a specific NuGet package? I know NuGet itself only allows you to set that at the base Nuget.config level. There are some internal packages that we would like to always get the latest version of (some of our database entities), while other internal packages we don't want to force a latest (our extensions package, for example). Right now we have to go through and manually update projects that rely on those packages, and I would like to automate those "always get latest" at build.
I don't see anything using any of the NuGet add-ins, but I am new to Cake so I'm hoping I am just missing something.
Has anyone had any luck using Cake to always retrieve the latest version on the feed for specific named packages, and just use the current packages.config version for the rest?
The short answer is that you can do anything that you want.
Cake out of the box will attempt to adopt established best principles for reproducible builds.
With the preprocessor directive, you could simply omit the version information, and Cake/NuGet will fetch the latest version. However, once downloaded to the tools folder, Cake/NuGet will not fetch it again. What you could do is add a custom step in your bootstrapper to clear the tools folder each time before build, and then the latest version will be downloaded each time.
Note: This is NOT a recommended approach, but rather something custom for your setup.
I am trying to install a package through nuget, which has the following dependency chain.
Acrobat 11.0.05 => Acrobat 11.0.04 => Acrobat 11.0.0 => Visual C++ 2010 Runtime
The exact error message I get is
Attempting to resolve dependency 'Acrobat (=11.0.04)'
Circular dependency detected 'Acrobat 11.0.05 => Acrobat 11.0.04'
I'm assuming that it considers these two packages to be the same, although they actually are not. The update to 11.0.05 is meant to be run on a working install of 11.0.04 which must be applied to an 11.0.0 install and must be installed in that order.
I know I could name them like AcrobatUpdate and AcrobatSecondUpdate instead, but that seems like a hack. If I can get this thing to work as intended, I'm certain my employer would prefer that.
Thanks in advance!
When authoring NuGet packages, it's encouraged to pack the everything that's at the current state and increment the version number of the package, instead of doing incremental content changes in packages for each version.
Or you could rename the dependent package to have a different ID.