I'm using Git as my source control and team city for running builds which compile a .net code base using FAKE script.
We want to be able to detect as a build check if someone has changed a library without bumping the version number.
Not all changes in the repository will require a new version of a nuget package to be created, only if a library which is packaged changes its version number.
This approach has a human error element to it of changing the library, but forgetting to bump the version and therefore it not being published.
Related
We have an .Net 6 API.
We have our own Nuget server to ensure we have backup of used Nuget packages so we always are sure we can run our CI chain.
After the upgrade to .Net 6, then every time MS publishes a new version of any of these three assemblies then our CI builds fail, because our NuGet server doesn't have the new version.
Microsoft.NETCore.App.Runtime.win-x64
Microsoft.AspNetCore.Runtime.win-x64
Microsoft.WindowsDesktop.Runtime.win-x64
Latest with 6.0.8. We then have to download the new packages to our Nuget server and then everything works.
In general I would like us to keep on known versions all the time, and only change referenced package version on purpose - and not just because developers publish new versions.
But I can't find any explicit references to these three packages.
Does anyone know where they come from - and more importantly - are there any way to lock our solution to use e.g. 6.0.8, until we decide to upgrade next time?
Best regards
/Anders
I'm using a Mac with Visual Studio 2019. I've added nuget packages: PostSharp and PostSharp.Community. I have NOT changed any code. I wasn't NOT prompted to select a license. I'm simply trying to compile, and I get the following errors.
/var/tmp/postsharp/cache/DependencyRestore/6.0.101/net6.0-sdk6.0.101-osx-x64--ps6.10.6.0-cf0d89f.deps.proj
: error NU3034: Package 'System.ValueTuple 4.4.0' from source
'https://api.nuget.org/v3/index.json': This package is signed but not
by a trusted signer.
/var/tmp/postsharp/cache/DependencyRestore/6.0.101/net6.0-sdk6.0.101-osx-x64--ps6.10.6.0-cf0d89f.deps.proj
: error NU3037: Package 'System.Security.Cryptography.ProtectedData
4.4.0' from source 'https://api.nuget.org/v3/index.json': The repository primary signature validity period has expired.
My project is targeting framework NetCore3.1. I don't know why PostSharp mentions net6.0.
As soon as I remove the PostSharp packages, it compiles fine.
Any help, would be greatly appreciated.
Thanks,
Jason
You probably have .NET 6.0 SDK installed on the machine and it is the active SDK (the highest version is usually used by default). PostSharp always executes under the runtime associated with the current SDK.
You should use the global.json file to specify SDK for .NET Core 3.1. This would cause PostSharp to run on .NET Core 3.1.
If this does not help, it means that PostSharp's dependency packages cannot be installed from nuget.org.
You can disable PostSharp's dependency restore by setting DependencyRestoreDisabled=True (either as env var or MSBuild property) and make sure that the project that was generated into /var/tmp/postsharp/cache/DependencyRestore/<SdkVersion>/<id>.proj has all it's dependencies present in the \var\tmp\postsharp\NuGetFallback directory.
Disabling the dependency restore disables automated checks and presumes that PostSharp can find all its dependencies on the machine.
I added the global.json, removed SDK 6.x. Set PostSharpDependencyRestoreDisabled=True and then I had to manually add all the referenced Nuget packages. It was annoying, but at least it works now.
Daniel, wetween both your responses, I was able to get it fixed!
Thanks!
I had a working IL-Repack post-build task in my project. Recently, I updated a number of libraries and now I have an issue that I cannot figure out.
My project uses Newtonsoft.Json and I have updated it to v12. My script is setup to take all dlls from the bin directory and merge them. When it gets to a certain dll (Twilio in this case), it gives this exception.
Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'Newtonsoft.Json, version=10.0.0.0, ...'. So I'm assuming that dll is looking for the Newtonsoft.Json but is getting confused by version?
Running the program from Visual Studio does not have any issues. Twilio requires Newtonsoft.Json 10+, so version 12 is ok. How do I get IL-Repack to recognize the v12 Newtonsoft? I can see that I've added Newtonsoft.Json for merge before Twilio is added.
This is for .net 4.7.2. IL-Repack 2.0.18 (current)
I have a .net (2.0) winforms application that I need to upgrade on client machines. At the moment this is done by incrementing the Assembly Version and File Version on all of the projects and incrementing the version on the Installer project in VS2008.
The application now makes use of Isolated Storage to save some user settings in an XML file (grid layouts etc...).
The problem I am now facing is that if I increment all the version numbers, the application has a new location for its Isolated Storage, because the File Version has changed. With a new location for isolated storage, all the settings have effectively been lost.
When upgrading does Windows installer replace the dlls based on the File Version or the Assembly Version?
If it is the Assembly Version then all I'd have to do is not increment the File Version.
Some good reading and discussion here:
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/6ed4d384-f6e9-42ee-b485-0bf40d0abd65/
To answer your question, though, I believe that MSI's respect FileVersion primarily:
File Versioning Rules
I want to create an MSI installer containing three apps. I will be releasing frequent updates to each app as I work through the list of feature requests and do bug fixes. The three apps are currently at versions 1.6.3, 1.6.12 and 1.8.1 respectively.
I was wondering what you guys can recommend for the version of the package. Should I:
Make the package version independent of the versions of the individual apps ?
Change the apps so they always have the same version as each other ?
Some other suggestion ?
Modify the package version each time the version of one of the apps changes. Then, you can look at the package version and know exactly which version of each app was being used.
Example:
Main version 1.4.1 has (1.6.3, 1.6.12, 1.8.1)
Main version 1.4.2 has (1.6.3, 1.6.13, 1.8.1)
Main version 1.5.0 has (1.7.0, 1.6.13, 1.8.2)
Main version 2.0.0 has (1.7.0, 1.6.14, 2.0.0)
So, if you're doing a minor version upgrade to one of your apps, the main application also goes up by a minor version number. Major changes to a sub-app result in the main app also getting a major version number change.