Marten: 1.0.0 nuget issue "Unable to resolve dependency 'Baseline'.

[mhov]

Installing 1.0.0 from nuget on a fresh .net 4.6 solution, and i see this error.

Unable to resolve dependency 'Baseline'. Source(s) used: 'nuget.org', 'Microsoft Visual Studio Offline

I know there are other similar issues that were closed recently but this seems to be new/current.

[jeremydmiller]

And it's there clear as day: https://www.nuget.org/packages/Baseline/. Are you sure that's not a connectivity issue?

[mhov]

Oddly enough, I can install Baseline 1.1.0 directly from nuget, after which the Marten 1.0.0 package _will_ install. I'm trying this across the a few different solutions and I get the same behavior though. I'm on nuget 3.5.0.1484.

[lngr]

Same here.

[jeremydmiller]

What version of .Net is your project? And how are you adding the Nuget?

[lngr]

Nuget v 3.4.4.1321 (PM console included in VS 2015 14.0.25123.00.

This project had an installed Marten version of 0.9.9.551.

When updating the following error occured (sorry for the German Text, but the exception translates to the above English error message).

PM> Update-Package Marten
Es wird versucht, Abhängigkeitsinformationen für mehrere Pakete bezüglich des Projekts "Happs.Backend" mit dem Ziel ".NETFramework,Version=v4.6.1" zu erfassen.
Es wird versucht, Abhängigkeiten für mehrere Pakete aufzulösen.
Update-Package : Die Abhängigkeit "Baseline" kann nicht aufgelöst werden. Verwendete Quelle(n): 'nuget.org', 'AHG'.
In Zeile:1 Zeichen:1
+ Update-Package Marten
+ ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Update-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.UpdatePackageCommand

PM> Install-Package Baseline
Install-Package : An error occurred while retrieving package metadata for 'Baseline' from source 'nuget.org'.
In Zeile:1 Zeichen:1
+ Install-Package Baseline
+ ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

I then manually installed Baseline 1.1.0 through the visual PM console and afterwards I could update to Marten 1.0.2, must as described by @mhov . I have no idea why.

[jeremydmiller]

Guys, I have no idea what's happening here. If this persists, I'll try to raise an issue w/ Nuget itself to see if they have any insight. For right now though, I'd like to close this.

[danielwertheim]

Same issue for me.

[danielwertheim]

Installing to a .Net Core lib works. Can it be something with Baseline explicitly supporting 4.5.1 and .Net Standard 1.3, so when installing Marten in 4.6+, it tries to resolve using 4.6 Marten dep and then don't use .Net Standard 1.3 for Baseline and 4.5.1 is to low. Can't try installing in 4.5+ since Marten doesn't state support for it. But easy test would be to just explicitly state 4.6 in Baseline as well.

As in adding 4.6 as well here: https://github.com/JasperFx/baseline/blob/master/src/Baseline/project.json#L13

[sandord]

I had the same issue (VS2015, Framework 4.6.1). Installing Baseline first and then Marten worked for me.

[wastaz]

Just as an additional comment here, if you use Paket (https://fsprojects.github.io/Paket/) instead of the normal Nuget client then everything is resolved perfectly fine.

So the easiest current solution is switching to paket (it's better than the default nuget client in every way anyway so... :) )

[Grummle]

Not directly related to Marten, but I get the same issue with Storyteller 4.1.1 and 4.0 just leaving this here in case a comparison of your 2 nugets similarities sheds any light.

Installing Baseline 1.2 explicitly works. No connectivity issues.

VS '15 U3

[bchavez]

Grrr... I'm using VS2017 latest update. I keep running into this ugly Baseline issue every time I update Marten. Please, please, if you can, remove the Baseline dependency from Marten (and maybe add sources manually) as Baseline only adds friction when updating Marten.

Here's my update process:

PM> Update-Package Marten

No package updates are available from the current package source for project 'X.Web.Core'.
Restoring packages for C:\Code\Projects\X\Source\X.Web2\X.Web2.csproj...
No packages were found in packages.config for project 'Builder'.


Attempting to gather dependency information for multiple packages with respect to project 'X.Data', targeting '.NETFramework,Version=v4.6.2'
Gathering dependency information took 6.43 sec
Attempting to resolve dependencies for multiple packages.
Update-Package : Unable to resolve dependencies. 'Baseline 1.2.0' is not compatible with 'Marten 1.5.1 constraint: Baseline (>= 1.3.0)'.At line:1 char:1
+ Update-Package Marten
+ ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Update-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.UpdatePackageCommand



md5-cfa469a1a111e3d5b1b0155501c46105



PM> Update-Package Baseline



md5-67812308e7b9f51a5ca26f8cd2335017



No package updates are available from the current package source for project 'X.Web2'.
No package updates are available from the current package source for project 'X.Web.Core'.
No packages were found in packages.config for project 'Builder'.


Attempting to gather dependency information for multiple packages with respect to project 'X.Data', targeting '.NETFramework,Version=v4.6.2'
Update-Package : An error occurred while retrieving package metadata for 'Baseline' from source 'nuget.org'.
  idAt line:1 char:1
+ Update-Package Baseline
+ ~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Update-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.UpdatePackageCommand

FML. That didn't work either... what now captin?

My choices for resolving this issue are slowly dwindling. Die Baseline, die a very slow death pls.

[jeremydmiller]

@bchavez I feel your frustration, but that's not happening for everybody. Have you tried just going into the csproj file and setting the Baseline version to 1.3? We made changes to the Baseline nuget to add explicit .Net 4.6 targeting (even though it already supported 4.5.1) specifically to address Nuget resolution issues. Honestly, can you raise an issue with Nuget itself, because this is their bug.

As for removing the Baseline dependency, if you feel strongly enough about this, feel free to send the pull request for it.

[bchavez]

@jeremydmiller Awesome. Thanks!

So, I looked into vaporizing the hard dependency on Baseline and was successful at tree-shaking all the unused code out of Baseline. A lot of junk fell out :wastebasket:. (Thanks with help from NDepened :+1:). Always feels good removing unused code. :raised_hands: :

So, here's what it looks like now:

I can shake the Baseline tree harder but ATM I'm aiming for the least impactful way without modifying Marten source files (at least for now). (No Marten *.cs files were harmed in this tree-shake).

In terms of maintainability, I know this might be a PITA for you to write code fixes in the Baseline repo and keep those changes in sync with the Marten repo. So, I created a Git submodule in src\Baseline and just only copied the classes that Marteen needed into src\Marten\Baseline (as shown in Solution Explorer above). Ideally, I'd like to set these Baseline classes with internal class so they don't pollute the namespace for users. The best way I can think of to make it as easy as possible for you to maintain would be to automate the process by leveraging the build system... and so that brings up my next few questions....

What is this rake, gem, ruby stuff? J/K :)

Would you be open to moving to a .NET build system like F# FAKE or C# CAKE? I'm not sure how popular Ruby is with .NET developers but I think it could make contributions easier by not having to install a ruby runtime. Using a propa .NET build system contributors can just walk up to a Command Prompt and hit build and done. As it is now, I gotta figure out how to get this ruby thing to work to make changes like this. :) You also wouldn't need a 3MB nuget.exe file in the repo. :) F# Fake + Paket does it all for us.

I've been using F# FAKE (build.fsx) with Bogus with much success. It's pretty complete with automated (and propa) GitHub releases w/ tags, (and thus fixing issues like #746 here in Marten). So easy, just tag the /master branch with vN.N.N and artifacts are built, nupkgs are published, and GitHub release is published. No drama OSS.

Would you be open to moving to AppVeyor?

It's nice. AppVeyor has PostgreSQL and works well for pushing artifacts to GitHub releases. I'm guessing TeamCity requires a bit more effort?

Do you want me to migrate Marten to new dotnet tooling (aka new CSPROJ)?

The Microsoft overlords say this .xproj stuff is legacy now....

---

Let me know how much you're willing to change (or reject). :+1: Let me know as soon as you can, I'd like to move fast here.

:beach_umbrella: :trumpet: Beach Boys - Good Vibrations (Nick Warren bootleg)

[wastaz]

@bchavez Now, don't get me wrong here. I'm not saying that I haven't cursed over problems with the Baseline dependency a couple of time in my life - however, consider that since Baseline has been a dependency for so long people using Marten may have started using stuff from Baseline as well (since it contains quite a number of useful utility methods that tbh should have been in the BCL). If you eliminate that dependency and instead put it inside marten as internal then you are causing a breaking change.

Now, it would be nice if Marten was self-sufficient, so a breaking change might not be that bad. But if this change is going in then I'd expect it to end up in 2.0 in order to respect semver? This of couse wouldn't solve the nuget woes in the 1.x versions - but as stated earlier, those problems can be solved by switching to paket (unless the nuget team actually gets off their asses and fixes their stuff, but I'm guessing that won't happen ¯\_(ツ)_/¯).

[mysticmind]

@bchavez few comments to your questions:

• We will be migrating to Appveyor soon. I had done some work earlier and posted a gist i.e. https://gist.github.com/mysticmind/b28c201697a3790036530497ebd22097
• Migrating to new csproj, I had sent a PR #755
• It would help to use Cake rather Ruby Rake. You can still build the solution from commandline without using Rake.

[danielwertheim]

@wastaz Why would dropping an external dependency be a breaking change, unless it has been used in such a way that users of Marten's public API has been forced to use pieces from it in their code base? But if it could be made internal to Marten like expressed above, I guess it hasn't. The people who has started to use Baseline as an effect of Marten can still have it as an external dependency. Agree that if the issue is in NuGet, then it would be great if it was fixed there. But if something can be done from project perspective other than stating something in the lines of "use Paket" that would in my mind be a nice gesture to people invested in NuGet, but of course, if it causes actual breaking changes, it should be planned.

[bchavez]

Hi, thanks for getting back. Indeed, @wastaz , I share your opinions about NuGet. When using it in very large projects it just stops working... :scream_cat:

@wastaz I see your concern about breaking changes. Indeed, perhaps it might be best to do this on 2.x release. However, I don't think Marten should be picking winners or losers over what "utility libraries" everyone should be using. I think it's safe to say you have your favs :heart: and I have mine :heart_decoration: .

Also, @mysticmind

• Great news on new *.csproj. Hopefully your changes get merged asap.
• Great news on Marten committing to use AppVeyor :+1:

Life will be better soon.

Also, one quick last thing, I've been tracking down a possible bug in Marten and stumbled upon some weird assembly versioning stuff.... (directly from NuGet package download):

If these X.Y.Z version numbers are supposed to match up; then all the more reason to get into a reliable, repeatable & automated build system asap and avoid hand-editing version numbers in source code repos...

Let me know when & where you'd like to receive this PR (if we are still interested in making this change).

Thanks,
Brian

:art: :dash: Marshmello - CoLoUR

[jeremydmiller]

I'm going to veto Cake. I'm doing somewhere around 90% of the dev work on Marten and I think Cake is awkward as hell to use. We can fix the common assembly info mechanics inside the Rake script -- or really, just eliminate it. I'd suggest for the folks that don't want to use Ruby/Rake that either:

1. You don't really need to use it. You can pull open VS.Net and just go. Just please run the unit tests at a minimum before committing
2. We can add a simple bash script that delegates to the dotnet cli to build and run all the tests

[jeremydmiller]

@danielwertheim I don't remember if the Baseline types are exposed in the Marten API at all, but it's a moot point because 2.0 is the master branch now and I really, really don't want to go through all the gymnastics of doing this in 1.5 just to turn around and do the same in 2.0 if I can help it.

@bchavez Baseline is my project, and it's a descendent of a utility project I've used for 7-8 years, so yes, I do get to choose the utility project that Marten itself uses. Baseline is pretty small, so I'm not really sure what the problem is here.

[jeremydmiller]

@bchavez Sorry, haven't been following this thread. I've discussed the Ruby thing ad nauseum in the past. I prefer Rake, didn't like the alternatives when other folks talked me into changing, I do 90%+ of the work on Marten, can't stand Cake, want nothing to do with Fake, think that Paket isn't very usable compared to the newer, built-in nuget management in the dotnet project system, and everything can be done by just calling the dotnet cli. I'm perfectly cool with a bash script so you and others will stop bitching about the rake script, but I'm not excited about being personally responsible for maintaining a build script in a tool I don't care for.

[bchavez]

Hey @jeremydmiller I agree with most of what you said. I don't like Cake either, so quite happy about that. And Paket does have it's problems, for sure.

I'm still unsure what to do... I kinda get the feeling based on what you said recently that you don't want to remove Baseline as a NuGet dependency now?

@jeremydmiller commented 2 days ago: .... As for removing the Baseline dependency, if you feel strongly enough about this, feel free to send the pull request for it.

Yes? No? If ( Yes ) PR to your /master 2.0 branch I take it?

---

@jeremydmiller commented 2 hours ago: ... Baseline is pretty small, so I'm not really sure what the problem is here.

The problem with Baseline, as others have pointed out, there are issues with using it as a NuGet dependency with Marten (and possibly more users more who don't report it). (details here, here, here, here, here, here, here, and here)

I would like to help you resolve these issues so that you don't have to do 90% of the work. :+1: We tend to bitch because we care (or at least that's what my girlfriend says). hahaha J/k :smile_cat:

:walking_woman: :ok_hand: Danelle & Salda - Nobody

[bchavez]

Also @jeremydmiller , your README says:

We're temporarily using rake for build automation, but it's not mandatory for development.

So, that's why I asked you about it and thought you were open to moving to something like F# FAKE or C# CAKE. But I see it's not the case so I'll send you a PR to fix that. :+1:

[jeremydmiller]

@bchavez I'm just not excited about doing that because it'll make my maintenance w/ Baseline a little more difficult if any of that stuff has problems later, that's all.

Sorry to be harsh, but the "why aren't you using Rake/Fake/Cake instead of [my personal preference]" thing is a pet peeve for me from lots of other projects. For Marten, we went down the NancyFx philosophy of "we like Rake, and we'll use that for ourselves, but users can just open VS and go".

Some of what you're seeing is historical detritus. We started on .Net 4.6 w/ the old Csproj model using Paket, then we switched to a hybrid model where we had parallel projects for project.json and Csproj, and then finally to only project.json. The nuget.exe in there is a leftover I just didn't remember to nuke. If you look in the Rake file, most of it is just delegating to the dotnet or npm/yarn command lines with the sh command.

[hellfirehd]

I don't have anything helpful to contribute but just wanted to chime in that I've been experiencing these Baseline nuget issues for a long time as well. I guess I'm glad I'm not the only one.

FWIW, I don't care what build system is used as long as I can forget about it and just get my work done.

[danielwertheim]

With regards to the build system there's very little to say if the main contributors and maintainers have found a nice setup that works for them. Especially if there is a friction free setup in being productive without even needing the build scripts (sounded like it). Of course you can always have another one in your fork. And eventually that might make it in there. Personally, I've gone through a few and currently Cake works good enough for me. I dropped Rake, as I didn't like having to install Ruby for managing ... builds.

@jeremydmiller regarding 1.5 vs 2.0... you are the one that knows what to prio with Marten so there's no real input to give. I have no idea how much effort there is in getting the code in both branches, but sounds like you have an excited contributor in @bchavez that seem eager to solve it. Awesome. So, if that (getting it in both branches) is done and there is no breaking change, why not "just" accept it? If included as source, you can always switch back when NuGet is "fixed", no? Of course, if it is a breaking then yes, wait for 2.0. But even if the bug is in NuGet the friction is experienced in Marten. And as an plain old fashioned dev, it would be awesome if it (read install of Marten) just worked with the mainstream paket manager, which in my mind is NuGet.