The dependency structuremap >= 4.3.0 could not be resolved

[tommed]

Trying to build asp.net core project whilst referencing StructureMap.Microsoft.DependencyInjection and getting back a build failure due to the dependency structuremap >= 4.3.0 - I can reference and build structuremap nuget package from my project, but this package fails to resolve its dependency. Relevant project.json:

 {
   "dependencies": {
   "MediatR": "2.1.0",
   "Microsoft.AspNetCore.Mvc": "1.0.0",
   "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
   "Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
   "Microsoft.AspNetCore.StaticFiles": "1.0.0",
   "Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0",
   "Microsoft.Extensions.Configuration.FileExtensions": "1.0.0",
   "Microsoft.Extensions.Configuration.Json": "1.0.0",
   "Microsoft.Extensions.DependencyInjection.Abstractions": "1.0.0",
   "Microsoft.Extensions.Logging": "1.0.0",
   "Microsoft.Extensions.Logging.Console": "1.0.0",
   "Microsoft.Extensions.Logging.Debug": "1.0.0",
   "Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
   "Microsoft.NETCore.App": {
       "version": "1.0.0",
       "type": "platform"
   },
   "StructureMap.Microsoft.DependencyInjection": "1.0.1-*",
   "Swashbuckle": "6.0.0-beta901",
   "Swashbuckle.Swagger": "6.0.0-beta901",
   "Swashbuckle.SwaggerGen": "6.0.0-beta901",
   "Swashbuckle.SwaggerUi": "6.0.0-beta901"
 },

 "tools": {
   "Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final"
 },

 "frameworks": {
     "netcoreapp1.0": {
        "imports": [
        "dotnet5.6",
        "dnxcore50",
        "portable-net45+win8"
     ]
   }
 },   
   "buildOptions": {
      "emitEntryPoint": true
   },
 }`

Results in error: project.json(20,59): error NU1001: The dependency structuremap >= 4.3.0 could not be resolved.

[tommed]

dotnet version = 1.0.0-preview2-003121

[khellang]

Related to #13, #14 and/or #16?

[tommed]

Yes! #13 thanks

[MarkPerryBV]

This is still an issue.

If you download the StructureMap 4.4.2 Package from NuGet and open up the StructureMap.4.4.2.nupkg file then inspect the StructureMap.nuspec file you will see that is the id is reported as:

   <metadata>
   <id>StructureMap</id>
   <version>4.4.2</version>

Which is not what you are saying the ID of the package should be. I have been battling all day to use StructureMap.Microsoft.DependencyInjection in a Asp.net Core project but it errors on my build server with "cannot find dependency structuremap >= 4.4.0" which is because the ID of the package has changed from the lowercase to the Cased version.

Or I am going mad (which is possible). Any chance you could check my findings?

[khellang]

This is still an issue.

Ugh. What a mess. I'm not really sure what to do here... 😞

@MarkPerryBV Did you try to update the NuGet client to 3.5?

The NuGet gallery is telling me that the package title is StructureMap, but the package ID is structuremap:

If you download the nupkg, you see that the package ID is structuremap:

But, if you pop open the nupkg and check the nuspec, it says that both the title and the package ID is StructureMap:

Who can you trust? How could a package ID suddenly change? What a clusterfuck.

@harikmenon @yishaigalatzer Anyone got any advice?

[MarkPerryBV]

I am using NuGet 3.5 on the build server.

I think its the nuget.exe you use to package the project to upload to NuGet.

[khellang]

Are you saying that @jeremydmiller must update his client to produce a proper NuGet package? 😕

[MarkPerryBV]

@khellang I have no idea how he produces the nupkg file to upload to NuGet feed.

One thought might be that there are 2 api feeds for NuGet (v2, v3) do you upload different packages?

[MarkPerryBV]

@khellang Visual Studio (2015 Update 3) also does NOT autocomplete the lowercase package name. In my project.json file it inserts it as:

"StructureMap": "4.4.2"

I tracked my particular problem down to the generation of the project.lock file (for the asp.net core project) and it had used the "StructureMap" as the name of the package which it could not find. As the package downloads as "structuremap.nupkg". Either way I think my issues will be resolved by "lowercasing" everything in all the places, but that will require you to bump the version numbers in the main repo and in this one.

[khellang]

The NuGet people has confirmed that this was a bug and that it's been fixed in 3.6RC. How that ties into Visual Studio and dotnet tooling, I have no idea...

[MarkPerryBV]

How do I get NuGet 3.6RC?

[khellang]

I'm not sure. For Visual Studio, you can probably use the beta channel, but it doesn't look like it's listed in the downloads section 😞

[khellang]

It's weird, cause I've never encountered this issue, and I've used this package in many many projects. I wonder if it's a very specific version of some tooling?

[joelverhagen]

@tommed, this error occurs during dotnet build right?

There is an issue in preview2 versions of .NET CLI (dotnet) where ID casing mismatches can lead to error message you are seeing. It looks like the StructureMap.Microsoft.DependencyInjection package has the following casing:

    <dependencies>
      <group targetFramework=".NETFramework4.5.1">
        <dependency id="Microsoft.Extensions.DependencyInjection.Abstractions" version="[1.0.0, )" />
        <dependency id="structuremap" version="[4.4.0, )" />
      </group>
      <group targetFramework=".NETStandard1.3">
        <dependency id="Microsoft.Extensions.DependencyInjection.Abstractions" version="[1.0.0, )" />
        <dependency id="structuremap" version="[4.4.0, )" />
      </group>
    </dependencies>

Notice that the ID of StructureMap is in there as structuremap. This should be changed to match the package author intended casing, which is visible in the StructureMap 4.4.0 .nuspec file (i.e. StructureMap).

The fix should be done here:

StructureMap.Microsoft.DependencyInjection/src/StructureMap.Microsoft.DependencyInjection/project.json

Line 27 in 395240b

"structuremap": "4.4.0"

A new version of the package StructureMap.Microsoft.DependencyInjection will need to be published.

Also, this problem is resolved in the next release of .NET CLI. Package IDs are intended to be case insensitive!

[khellang]

This should be changed to match the package author intended casing, which is visible in the StructureMap 4.4.0 .nuspec file (i.e. StructureMap).

@joelverhagen The problem is that this was never the intended casing (or maybe it was, but it's been structuremap (lowercase) since day 1). It suddenly changed when @jeremydmiller switched to the dotnet tooling to produce the NuGet packages. Check the NuGet history of the structuremap package to see what I mean. How could a package suddenly change its ID?

[jeremydmiller]

"How could a package suddenly change its ID?" - apparently pretty easy. I'd completely forgotten about the old Unix-y "structuremap" name and set up the package.json with the way we normally type it out.

[joelverhagen]

Each package defines its own ID and version. NuGet.org aggregates them by case-insensitive package ID. Concerning how it suddenly changed, it looks like StructureMap is a project.json project itself. By default, the package ID is set to the directory name when packing a project.json:

I'm not sure what the StructureMap build process is, but that's my best guess on how it changed from one version to the next.

[MarkPerryBV]

So is there a fix to be applied? If so what do I need to do?

[joelverhagen]

1. Owner of StructureMap package should decide which ID casing to use. I would recommend StructureMap since that is what the latest versions have. If necessary, release a new version with the correct case.
2. Owner of StructureMap.Microsoft.DependencyInjection should depend on StructureMap or structuremap depending on what the owner of StructureMap decides and release a new version.

[tjrobinson]

Any updates on this? Is there a workaround I can apply in the meantime?

[tjrobinson]

I've worked round this by downloading the StructureMap.Microsoft.DependencyInjection.nupkg and modifying it to depend on StructureMap instead of structuremap and giving it a prerelease version number, then uploading it to our private MyGet feed. It resolves the problem for now. A more public way of doing it would be to take a fork and publish it to nuget.org.

[khellang]

Concerning how it suddenly changed, it looks like StructureMap is a project.json project itself.

@joelverhagen Wouldn't you consider this a bug? The fact that the package ID of an already published package can change between versions and break clients, regardless of the package ID in the nuspec, sounds really really bad IMO.

[khellang]

OK everyone. I've finally pushed a new version, v1.3.0, to NuGet. I've changed the dependency on SM to StructureMap (v4.4.2). Let me know if this resolves your issues.

[tjrobinson]

@khellang Thanks for doing this - unfortunately it doesn't work for us as 1.3.0 also changes the dependency on Microsoft.Extensions.DependencyInjection.Abstractions from >= 1.0.0 to >= 1.1.0 (which in turn has dependencies on the 1.1 .NET Core packages) as well. Is there any chance you could push out a 1.2.1 that just includes the StructureMap fix?

[khellang]

I'll see if I can fix this later today 😄

[tjrobinson]

Thanks 👍

[khellang]

@tjrobinson Pushed a new version, v1.2.1, that only changes the StructureMap dependency casing (and bumps it to 4.4.2).

[tjrobinson]

@khellang That works for us, thanks.

[joelverhagen]

The fact that the package ID of an already published package can change between versions and break clients, regardless of the package ID in the nuspec, sounds really really bad IMO.

Package IDs have been case-insensitive on the nuget.org gallery for quite a while now (years), so we have to take this as a preset to our problem 😄. There are numerous cases in the gallery where users change a package ID casing from one version to the next. In recent NuGet releases, we have done a lot of work to improve the case-insensitivity handling but, as you can see, there are still places that are catching up.

The root cause here is a bug in .NET CLI preview 2 build (dotnet build). So instead of this being a NuGet ecosystem bug, I would assert this is a bug in one step of the package consumption story. It is unfortunate that this is a preview 2 bug because .NET CLI has moved on to subsequent releases. I think the only way people can address this fix is either:

1. Update to a newer version of .NET CLI, and therefore lose .NET Core project.json support.
2. Do the workaround you performed on their packages, and therefore can remain on preview 2 tooling.

Please let me know if you have any other feedback 👍.

[khellang]

So what you're saying is that once the bug is fixed, I won't have to change the dependency back to the old casing?

If that's correct, then I think we're done here. Fingers crossed all the NuGet casing bugs have been resolved.

Thanks for your time, @joelverhagen ❤️

[joelverhagen]

So what you're saying is that once the bug is fixed, I won't have to change the dependency back to the old casing?

Correct. And to be clear the bug is actually already fixed in preview3+ .NET CLI builds (which implies .csproj instead of project.json).