In our project we're creating different NuGet packages (using suffixes) for different branches. In the .csproj file I'm trying to specify the specific version of a package that should be used.
Package names can be 1.2.3, 1.2.3-rc001, or 1.2.3-pr001.
First issue:
I tested using
<PackageReference Include="Package.Name" Version="[1.2.3,1.2.6)" /> where there was no 1.2.3. My understanding is it should use the next available version, but now it simply says the selected package is 1.2.3, with "Not available in this source". Updating NuGets also ignores this and simply updates to the latest release, 1.2.10. After that it overwrites the Version in .csproj, so the specified bounds are lost.
Second issue, that falls in with the first, is to specify to only use -pr* or -rc* versions. 1.2.*-pr* is not a valid option, so maybe our numbering scheme needs changing.
First issue: I tested using where there was no 1.2.3. My understanding
is it should use the next available version, but now it simply says
the selected package is 1.2.3, with "Not available in this source".
Actually, when you set different versions of a nuget package by floating versions(in your situation, 1.2.3<=version<1.2.6), NuGet chooses the package that's closest to the application and ignore the others. So it will choose 1.2.3 regardless of whether it exists in your current nuget caches.See this document.
So PackageReference will not reference the package based on the closest available version in your current cache and choose the newest version not matter whether it exits under your local machine.
Second issue, that falls in with the first, is to specify to only use
-pr* or -rc* versions. 1.2.-pr is not a valid option, so maybe our numbering scheme needs changing.
At the moment, prerelease versions cannot be used together with floating versions.It means that you cannot use any pre-release characters with floating versions . So -pr* and -rc* are illegal including 1.2.*-pr*.
During use, no characters about the pre-release version can appear.
Instead, you can use
1.2.*-*
Besides, the 1.2.*-beta1 is also illegal. Though it shows a version under Dependencies UI, you can not find it under Nuget Package Manager-->Installed which means that the package is missing and the project has lost it.
In addition, there is a similar issue which you can refer to.
Related
I'm using VS2022, and I received an old project, where iTextSharp was used, but I can't determine a specific version of the mentioned.
I've tried - Tools -> Nuget Package Manager -> Manage Nuget Packages for Solution...
But was unable to find iTextSharp.
Thanks in advance.
It sounds like the assembly has been included directly in the source control, as was common place before nuget. Take a look in your project's references and you should be able to locate the dll. Checking the file's properties in VS should show you the assembly's details in the properties panel and should also show you which version is being used, if not the path or filename may give you a clue as to the version being used.
when I'm examining some VS installer logs from different computers to check for differences
for example: dd_setup_2019123333.log:
there are some lines like:
> Package: Microsoft.Net.Core.SDK.MSBuildExtensions,version=15.9.28307.51,
> CurrentState: Absent, RequestedState: Present, DetectionState: Absent,
> PlannedAction: Install.
there will be also further entries and a dd_setup_201911312323_Microsoft.Net.Core.SDK.MSBuildExtensions.log file with more detailed steps.
How do I find the VS workload or components that depends on that package, so I am able to install it properly by defining VS components? Where else could I find the source of that package?
and if I want to check it vice versa:
> Property: InstallationWorkloads, value:
> Microsoft.VisualStudio.Workload.CoreEditor,Microsoft.VisualStudio.Workload.ManagedDesktop,Microsoft.VisualStudio.Workload.NetWeb
2nd question: where do I find, what's included in e.g. Microsoft.VisualStudio.Workload.NetWeb?
Edit:
Answer for 2nd Q is mostly here:
First of all, please let me introduce the relationship between packages, components and workloads.
If we install a workload, some components are required by that workload to install, some are recommended and others are optional.
And if we install a component, several packages will be installed for that component.
Eg: If I install a component "Microsoft.VisualStudio.Component.Unity", apart from the "Microsoft.VisualStudio.Component.Unity" package, some packages which have dependency with it also will be installed such as "SyntaxTree.VisualStudio.Unity.Msi,version=3.9.0.3" package.(We can find them in C:\ProgramData\Microsoft\VisualStudio\Packages)
How do I find the VS workload or components that depends on that
package?
For most packages, we can find which component and workload depends on it according to this document.
However, for the package" Microsoft.Net.Core.SDK.MSBuildExtensions", it seems a package which the component package depends on or in a sdk. So we can’t locate accurately which component the package belongs to because not only one component or workload depends on it.
As the picture below: We can find the workloads and components which depend on it by the log .
Where else could I find the source of that package?
In the log, you can check if there has a download url for you to manually install it. And I find a download url(for version=15.9.28307.272) :
https://download.visualstudio.microsoft.com/download/pr/b78321cf-2968-49be-a845-fb99347d436e/f938871be0a92ffda7bf6bb1f8c2015f/payload.vsix Hope it helps.
Where do I find, what's included in e.g.
Microsoft.VisualStudio.Workload.NetWeb?
You can find them here.
The Context
This question is related to the RAMDisk Storage Driver Sample, but also applies to the Toaster Sample Driver, and may even apply to any driver that make use of .INX files and CoInstallers.
My original question was "Why am I missing the WdfCoInstallerXXXXX.dll file when my build was successful?" After reviewing the ramdisk.inf file, I realized that all the coinstaller sections are empty (replaced with a semicolon). This lead me to the question below.
The Question
The coinstaller section of the ramdisk.inx file make use of the $KMDFCOINSTALLERVERSION$ variable. This should be a valid variable according to this page. However, upon successful build, all lines that reference the $KMDFCOINSTALLERVERSION$ variable evaluate to a semicolon in the generated ramdisk.inf file. Why?
Additional Information
All other variables in the ramdisk.inx files, such as $KMDFVERSION$ and $ARCH$, gets evaluated properly.
The Cause
It turns out that the cause of this was the fact that I don't have the specified KMDF library version install, even though I recently installed the latest WDK 10. According to this page, "if you omit the KMDF Version Minor, the most recent minor version is used."
In other words, I was trying to use KMDF version 1.15, when I only support 1.7, 1.9, and 1.11. You can check the redistributable directory to see which version you support. Mine is located at C:\Program Files (x86)\Windows Kits\10\Redist\wdf\x64.
The Fix
Go to Project->Properties->Driver Settings->Driver Model, and select the appropriate KMDF version. After that, rebuild, and your .INF file will be properly populated, and your driver package will contain the appropriate WdfCoInstallerXXXXX.dll.
I had to download a different version from a DLL, but now this new version requires 4 other DLLs, which I don't want to add into my package. Since I'm not even using them, it would be a waste of space.
Is it somehow possible to edit the DLL and make it ignore the missing dependencies which aren't even used?
I'm talking about libgd2.dll, and since the website is down, I was unable to find the old version of this library, so I had to download this newer version. Earlier I had bgd.dll, but now I can't find the old bgd.lib file anywhere on the web.
I've inherited a .NET application that automatically updates it's version number with each release. The problem, as I see it, is the length and number of digits in the version number.
An example of the current version number format is 3.5.3167.26981 which is a mouthful for the users to say when they are reporting bugs.
What I would like is something more like this: 3.5 (build 3198). I would prefer to manually update the major and minor versions, but have the build number update automatically.
Even better, I don't want the build number to increment unless I am compiling in RELEASE mode.
Anyone know if there is a way to do this -- and how?
In one of the project files, probably AssemblyInfo.cs, the assembly version attribute is set to [assembly: AssemblyVersion("3.5.*")] or something similar. The * basically means it lets Visual Studio automatically set the build and revision number.
You can change this to a hard coded value in the format <major version>.<minor version>.<build number>.<revision>
You are allowed to use any or all of the precision. For instance 3.5 or 3.5.3167 or 3.5.3167.10000.
You can also use compiler conditions to change the versioning based on whether you're doing a debug build or release build.
At a previous company we did something like this by writing an Ant task to get the current Subversion changeset string, which we used as the build number, appended after the major, minor, and tertiary numbers. You could do something like this with Visual Studio as well.
Use a '*' wildcard in the AssemblyVersion attribute. Documentation is here. Note that if the application is built from multiple assemblies, the version you care most about is the one for the .exe.