Reputation: 248
I'm having issues with NuGet prerelease packages and was wondering what others had done in this situation. NuGet functionality seems completely different, and frankly, strange, from expected behavior in Maven. For a quick example, let's say we have assemblies FooAssembly and BarAssembly, with classes defined as follows:
Foo:
namespace Foo {
class FooClass {
public void TestA(){
}
}
}
Bar:
namespace Bar {
class BarClass {
public static void Main(string[] args){
FooClass foo = new FooClass();
foo.TestA();
}
}
}
When I build Foo, it's versioned such that it generates Foo-1.0.0-SNAPSHOT.nupkg. NuGet installs this into Bar when I add it as a dependency, placing it in both my local cache under %APPDATA% and a packages folder in my source tree. Now, if I add method TestB() to Foo, and rebuild, it also generates Foo-1.0.0-SNAPSHOT.nupkg. My build places this new nupkg file into my %APPDATA% cache as expected. However, when I try to do a rebuild of Bar, NuGet doesn't detect that my nupkg in %APPDATA% has changed, and therefore doesn't have the new TestB method available. I have to manually delete the src/packages folder (or at least the Foo subdirectory in packages) for it to reacquire the package from my cache.
In Maven, if I were to rebuild Foo with the TestB method added, it would place Foo-1.0.0-SNAPSHOT in my .m2 cache, and Bar would link against the new version of the jar and would know about TestB.
My question is, firstly, am I missing something with NuGet? Secondly, if I'm not, what have people done to work around this shortcoming? Add an MSBuild pre-build step to wipe out the project package cache? Append build numbers to the end of SNAPSHOT (e.g. SNAPSHOT42...this seems like it would be problematic with more than one developer on the project)?
Any insight is appreciated. Thanks.
Upvotes: 3
Views: 1440
Reputation: 8243
As of 2018, this answer is out of date - see my other answer for updated information.
NuGet doesn't really support SNAPSHOT dependencies like Maven does, although there is an open issue to implement something similar and a discussion about such functionality.
A possibility suggested was to write a script to:
Alternatively when I work on my own projects, I always build and reference Foo
from source. Then, once Foo
project becomes stable enough that I don't update it much anymore, I then start stop referencing Foo
via source and instead build it and reference as a nuget package.
Upvotes: 2
Reputation: 8243
If you use PackageReference
elements inside of the new csproj file format, you can now using floating versions.
For builds from Visual Studio, you'll need to explicitly rebuild to pickup the changes. For non-Visual Studio builds, you'll need to -force
updates as noted in an issue discussing open versions and updates.
Upvotes: 2