I developed a (non-public) nuget-tool. The installation was very easy:
dotnet tool install dotnet-mytoolname -g
My colleagues will also install these tool by the command.
In future I will release new versions of dotnet-mytoolname. Consumers will update it easy with dotnet.exe.
Now my problem:
If a developer runs an outdated version of that tool then I will hint it in console output (something like "a newer version is available").
How I can check with dotnet.exe if a new version is available?
The command below would do it but only for nuget.org. But our nuget-tool is not hosted on nuget.org but on a private azure-devops server.
dotnet tools search dotnet-mytoolname
The nuget-tool dotnet-mytoolname is a C# console-project.
Have you any ideas how I can check within that project if a newer version is available on azure-devops?
Thank you DavidG. Posting your suggestions as an answer to help other community members.
Installing dotnet outdated application will help you in resolving your issue
install .Net core and run the following command
dotnet tool install --global dotnet-outdated-tool
Here is how it will use
Usage: dotnet outdated [options] <Path>
Arguments:
Path The path to a .sln, .csproj or .fsproj file, or to a directory containing a .NET Core solution/project. If none is specified, the current directory will be used.
Options:
--version Show version information
-?|-h|--help Show help information
-i|--include-auto-references Specifies whether to include auto-referenced packages.
-pre|--pre-release <PRERELEASE> Specifies whether to look for pre-release versions of packages. Possible values: Auto (default), Always or Never.
-vl|--version-lock <VERSION_LOCK> Specifies whether the package should be locked to the current Major or Minor version. Possible values: None (default), Major or Minor.
-t|--transitive Specifies whether it should detect transitive dependencies.
-td|--transitive-depth <TRANSITIVE_DEPTH> Defines how many levels deep transitive dependencies should be analyzed. Integer value (default = 1)
-u|--upgrade[:<TYPE>] Specifies whether outdated packages should be upgraded. Possible values for <TYPE> is Auto (default) or Prompt.
-f|--fail-on-updates Specifies whether it should return a non-zero exit code when updates are found.
-inc|--include <FILTER_INCLUDE> Specifies to only look at packages where the name contains the provided string. Culture and case insensitive. If provided multiple times, a single match is enough to include a package.
-exc|--exclude <FILTER_EXCLUDE> Specifies to only look at packages where the name does not contain the provided string. Culture and case insensitive. If provided multiple times, a single match is enough to exclude a package.
-o|--output <OUTPUT_FILENAME> Specifies the filename for a generated report. (Use the -of|--output-format option to specify the format. JSON by default.)
-of|--output-format <OUTPUT_FILE_FORMAT> Specifies the output format for the generated report. Possible values: json (default) or csv.
-ot|--older-than <NUMBER_OF_DAYS> Only include package versions that are older than the specified number of days.
Check this link which will give you complete information about dotnet outdated packages.
Related
I want to create a .Net class library and allow the users the option to either use the DLL or the C# source directly.
I know how to pack DLLs. I know how to pack source only packages (although it doesn't work for SDK style libraries). But I don't know how to allow the users to chose one.
This question has no answers and suggests that setting a default value for <IncludeAssets> is not possible. So by default both will be included and might cause conflict ?
This SO answer suggests to create two multiple NuGet packages like Foo and Foo.Sources. But I don't know how to do that in a neat workflow for a single solution/project either.
Any suggestions/resources or even example packages would be helpful.
I have a .NET 5.0 console application. How can I create a version resource and then display that version in my application?
In the past, I have seen an AssemblyInfo.cs file. But I don't see anything like that in my new project.
I had to solve this problem recently: how do you know which version of a tool is deployed? And how can you automate the version number, so you don't accidentally use an old version?
In the past, that information was stored as attributes in AssemblyInfo.cs. In .NET Core, those attributes are now generated by project properties at runtime.
Andrew Lock explains how the various properties like Version, VersionPrefix, VersionSuffix,AssemblyVersion FileVersion, PackageVersion, InformationalVersion are used.
The most important ones are Version, VersionPrefix and VersionSuffix. That's because Version is used as the default for the other ones. Version in turn can be calculated as VersionPrefix-VersionSuffix if there's no explicit value.
Quoting the article:
The Version property is the value most commonly set when building .NET Core applications. It controls the default values of all the version numbers embedded in the build output, such as PackageVersion and AssemblyVersion so it's often used as the single source of the app/library version.
If you use System.Commandline, the version info displayed by --version is the InformationalVersion whose default comes from Version.
The default VersionPrefix is 1.0.0 and the default suffix is empty, resulting in version 1.0.0.
*Formulas
The nice thing is that the properties can have formulas. I was able to automatically generate a date-related version number simply by adding this to a csproj that contains no other version information
<VersionSuffix>$([System.DateTime]::UtcNow.ToString(`yyyyMMdd-HHmm`))</VersionSuffix>
Each time I build my tools now I get versions like 1.0.0-2021061501836
Overriding the properties
The project values can be overridden during build, either by specifying an explicit version suffix, or specifying an explicit value for the project properties, eg :
dotnet build --configuration Release --version-suffix preview2-final
Or
dotnet build --configuration Release /p:Version=1.2.3-preview2-final
This way, an automated release pipeline can specify a new version that overrides anything set in the project file
I want to create an Minor Upgrade for a product, I already define a WIX project that generates the MSI installer .
Directions from Microsoft states that in a Minor Upgrade, the ProductCode should not be changed, but ProductVersion must be changed.
Furthermore I change the AssemblyInfo of my application in order to match the ProductVersion. The change in the AssemblyInfo involves change for the AssemblyVersion and AssemblyFileVersion.
After these changes I generate another installer, and now I have two installers:
Installer_1.0.1.msi (A)
Installer_1.0.2.msi (B)
I installed A (double click) then proceed to Install B (double click), but I got this:
Microsoft states that to apply a minor upgrade I should see how to apply a Small Update, I choose to try Reinstalling the product :
The steps described suggest to use the command
msiexec /I Installer_1.0.2.msi REINSTALL=ALL REINSTALLMODE=vomus
Checking the msiexec command line reference I found that:
v: Runs from source and re-caches the local package
o: Reinstalls if file is missing or if an older version is installed
m: Rewrites all required computer-specific registry entries
u: Rewrite all required user-specific registry entries
s: Overwrites all existing shortcuts
That's what I need!!! (I thought to my self).
Tried the command, the result was:
No file was changed
The version in control panel/Programs changed
The installer cache change and I was not able to uninstall the product from Control Panel/Programs/Uninstall
I proceed to change the command parameter o for a because it Forces all files to be reinstalled.
Same result.
My objective is to be able to change the files without having to manually uninstall the product (This can be achieve with a MajorUpgrade, but it implies the change of the ProductCode).
What am I missing in this process?
UPDATE:
If I setup the ProductCode to be dynamic it works as expected, but it would become the minor upgrade in a major upgrade (According to the technical library).
The question is somewhat older, but the correct answer is:
What you have done, works, if done right, the two main points are:
Package Id should be different of new version (minor upgrade)
(but) use REINSTALLMODE=vemus instead of vamus in a production environment , the latter is a worst practice pattern, and if you use it, then only for a quick test ("all files overwritten, no matter which version").
So the command line is:
msiexec /I Installer_1.0.2.msi REINSTALL=ALL REINSTALLMODE=vemus
This surely works. "Only" (yes) files which have been changed after the first installation (by manual edit or changed with a program) will not be updated (for safety). You will need other methods for this (look for "companion file(s)").
But the described way of a minor upgrade though feasible is not to recommend for a production environment, maybe only for MSI experts.
1.
At least, update the file versions of all files in the setup, then you don't have to rely on "vemus" (or vamus), and moreover, you don't loose the overview and error possibilities are highly minimized.
2.
It is recommended by most sources (and I would agree) to not use Minor Upgrades because Major Upgrades work smoother, especially for non experts.
If install performance is a point, you can even use the uninstall old version after install pattern there (means "only", the action "RemoveExistingProducts" is at the final part of the setup (see MSDH help for this)).
3.
Next step of complexity (but you have to deal with) is using Patches (.msp files) as non full updates.
For Minor Upgrades you have to have same ProductCode and UpgradeCode. But you have change the ProductVersion, Package GUID and also the versions of the binaries (DLL & EXE files) in the MSI package should be greater than the previous version
It seems that versioning works differently than in previous versions of .Net. The project.json seems to use semantic versioning (from what I have seen online) with the format Major.Minor.Patch-Special.
Does this replace the Assembly version idea or add to it? Or does it just get used with Nuget.
How does one access the version during runtime. I came across Nuget.SemanticVersion object online in the Microsoft.Framework.Runtime package but I can't find out how to retrieve it in code.
Is there a programmatic way to update this value on a build or just custom scripts?
I wouldn't say that versioning has changed in a particularly dramatic way. In a version number x.y.z, the "x" means "big changes / breaking changes," the "y" means "minor additions and fixes," and the "z" means "very minor fixes." That's pretty close to what Semantic Versioning (SemVer) states.
In a project.json-based project, there is only one place to specify the version, and that's in the project.json file itself. That one version is a SemVer (e.g. x.y.z-prerel) and is used for the NuGet package version and the assembly version, and the assembly informational version. If you've explicitly set the assembly version or informational version in the assembly, those will be respected and not overridden. (You can see the code here.)
At runtime you can read the assembly version through reflection (just like you always could).
When running in a DNX application there's also an ILibraryManager interface that you can use to inspect the running application. However, that's a fairly advanced scenario.
Lastly, in the project.json file you can hard-code the x.y.z part of the version, e.g. 1.2.3 but you can also specify a * for the pre-release specifier, e.g. 1.2.3-*. If you use * for the pre-release specifier, you can set an environment variable named DNX_BUILD_VERSION to specify the value of the *, e.g. beta1 or rc2-54289.
There are some feature requests logged to allow more flexibility in specifying the entire version number externally.
In my current project, I'm producing weekly releases. I've been using the technique described in this post to keep the version numbers of all of the assemblies in my project in sync. (I don't presently have any good reason to track the assemblies' version numbers separately, though I'm sure that day will eventually come.)
When I push out a release, I build a new version of the installer. Unlike all of the assemblies, which can get their version numbers from a shared SolutionInfo.cs file, the version number of the installer isn't, as best I can tell, an assembly property. So my release process includes manually advancing the version number in the setup project.
Or, I should say, usually includes doing that. I'd like to turn that into something I can't screw up. I'm finding the documentation of setup and deployment projects to be surprisingly opaque (it was quite a bit harder to find out how to make it possible for the MSI to uninstall properly if the user installed it to a non-default path, which is a pretty freaking common use case to be undocumented) and have no idea if it's even possible to do this.
Any ideas?
Edit:
Just to clarify, this is a Visual Studio setup and deployment project I'm talking about.
CodeProject has a script to set the version number of an MSI file, which you could run in the pre-built step of the setup project. You find it here:
http://www.codeproject.com/KB/install/NewSetupVersion.aspx
More Details
Be aware that with Windows Installer things are a bit more complicated. MSI files (as the one that you create using a VS Setup and Deployment project) not only have a version number but also a product code which is a GUID value. This product code is used by Windows Installer to uniquely identify your product e.g. in Control Panel -> Add Or Remove programs where you can decide to uninstall or repair a product.
However, when changing you MSI version number, this product code must also be changed in a number of cases. MSI technology is poorly documented but you can find some recommendations when to also change the product code on the following MSDN page: http://msdn.microsoft.com/en-us/library/aa367850(VS.85).aspx.
In my projects I always generate a new product code for every new version. The script on CodeProject will also change the product code for you.
And one more thing: Windows Installer only checks the first three places of the version number afaik, anything in the forth place will be ignored, i.e. 2.3.0.1234 is considered equal to 2.3.0.5678. (ProductVersion)
(There is a related article on CodeProject which might also be interesting to you: http://www.codeproject.com/KB/install/VersionVDProj.aspx)
Its going to depend on the installer toolkit you are using.
We use TFS Team Build and WiX v3. I have a custom build task that increments the build number in Team build (5.0.0.X for example), then this version number is pushed to the common AssemblyInfo.cs AssemblyFileVersion field. It is also passed by MSBuild to our solutions/projects as a property which is then passed into WiX and used to update the installer version as well.
We probably will need to do better with the assembly versioning someday as well, but right now this has been working pretty well for us.
I use a workaround for VS2010 Setup projects (.MSI + setup.exe). Open the .vdproj in Notepad and edit the ProductVersion assignment value (3.2.1 in the example below). Save the file and launch VS2010 by double-clicking on the .vdproj file.
"Product"
{
"Name" = "8:Microsoft Visual Studio"
"ProductName" = "..."
...
"ProductVersion" = "8:3.2.1"
"Manufacturer" = "..."
...
}