Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ship update to Microsoft.Composition #14653

Closed
terrajobst opened this Issue Dec 21, 2016 · 13 comments

Comments

Projects
None yet
8 participants
@terrajobst
Copy link
Member

terrajobst commented Dec 21, 2016

With #6598 we've decided to discontinue the package Microsoft.Composition in order to favor our new naming convention and instead ship it under the name System.Composition.

In order to pull customers forward, we should:

  • Ship a last version of Microsoft.Composition
  • Make that version empty and make it depend on the System.Composition package
  • Add a readme.txt that informs customers that this package is discontinued and that the new package is System.Composition

Without this, customers will be surprised if they use Microsoft.Composition and install other packages that depend on System.Composition (such as Roslyn) as they now get compilation errors as there are now two packages that provide the same set of assemblies.

An updated Microsoft.Composition doesn't solve this per-se, but when customers run into this issue they are likely looking for updates to the involved packages and check whether upgrading solves this issue -- which it will.

@davidfowl

This comment has been minimized.

Copy link
Contributor

davidfowl commented Dec 21, 2016

Does this apply to the other Microsoft.* packages shipped?

@mellinoe

This comment has been minimized.

Copy link
Contributor

mellinoe commented Dec 22, 2016

@davidfowl We only renamed this package because the actual assemblies inside of it have always had a different name ("System.Composition.*"). It's an attempt to make things consistent.

The other "Microsoft.*" packages already have assemblies with matching names, so there's no need to change them.

@AlexGhiondea AlexGhiondea added this to the Future milestone Dec 22, 2016

@AlexGhiondea

This comment has been minimized.

Copy link
Member

AlexGhiondea commented Dec 22, 2016

@mellinoe @terrajobst can this be closed?

@AlexGhiondea AlexGhiondea added the bug label Dec 22, 2016

@terrajobst

This comment has been minimized.

Copy link
Member Author

terrajobst commented Dec 23, 2016

[@mellinoe] The other "Microsoft.*" packages already have assemblies with matching names, so there's no need to change them.

Yes, there is two types of packages:

  1. Packages where assemblies and packages use different naming. Examples are:
    • Microsoft.Net.Http -> System.Net.Http
    • Microsoft.Bcl.Immutable -> System.Collections.Immutable
    • Microsoft.Bcl.Metadata -> System.Reflection.Metadata
    • Microsoft.Composition -> System.Composition
  2. Packages where assembly, namespace, and package name are aligned on Microsoft. Examples:
    • Microsoft.AspNet.*

We don't need to make any changes to packages in the second category, but we do need to make changes for the first. And except for Microsoft.Composition we've already shipped "forwarding" updates as requested by this bug.

So:

[@AlexGhiondea] can this be closed?

No, unless we shipped said forwarding update :-)

@CZEMacLeod

This comment has been minimized.

Copy link

CZEMacLeod commented Feb 14, 2017

Any timescale for this forwarding package as I have run into this problem a couple of times now?

@terrajobst

This comment has been minimized.

Copy link
Member Author

terrajobst commented Feb 17, 2017

Any timescale for this forwarding package as I have run into this problem a couple of times now?

You can work this around by following these steps:

  • Uninstall Microsoft.Composition
  • Install System.Composition
@CZEMacLeod

This comment has been minimized.

Copy link

CZEMacLeod commented Feb 17, 2017

Unfortunately that doesn't really address the issue where I rely on 2 packages, one of which depends on Microsoft.Composition 1.0.30 and one on System.Composition 1.0.31, especially during package restore and/or CI builds.

@daveaglick

This comment has been minimized.

Copy link

daveaglick commented Apr 11, 2017

I'm seeing some problems that might be related to this. I'm using Roslyn 2.0 bits in a 4.6.2 library and attempting to create an MSBuildWorkspace. I now get this runtime error:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Composition.TypedParts, Version=1.0.27.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Composition.TypedParts, Version=1.0.27.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Microsoft.CodeAnalysis.Host.Mef.MefHostServices.Create(IEnumerable`1 assemblies)
...

So okay, no problem, I'll just uninstall `Microsoft.Composition" and install "System.Composition" instead:

Unable to uninstall 'Microsoft.Composition.1.0.30' because 'Microsoft.CodeAnalysis.Workspaces.Common.2.0.0' depends on it.

I went ahead and installed System.Composition in the project in addition to Microsoft.Composition, and it seems to work, but now I feel dirty for having both.

But, wait! It's not over yet. Now that I've got System.Composition.TypedParts and Roslyn can find it, I'm getting a different FileNotFoundException for System.Diagnostics.Tools. This is where it gets confusing to me. The System.Diagnostics.Tools package doesn't contain a System.Diagnostics.Tools.dll assembly and instead has one of those _._ placeholders for net45. It does have an assembly for netstandard1.0. In any case, it looks like System.Composition.TypedParts wants System.Diagnostics.Tools, which doesn't exist in my 4.6.2 project:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Diagnostics.Tools, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Diagnostics.Tools, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at System.ModuleHandle.ResolveType(RuntimeModule module, Int32 typeToken, IntPtr* typeInstArgs, Int32 typeInstCount, IntPtr* methodInstArgs, Int32 methodInstCount, ObjectHandleOnStack type)
   at System.ModuleHandle.ResolveTypeHandleInternal(RuntimeModule module, Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)
   at System.Reflection.RuntimeModule.ResolveType(Int32 metadataToken, Type[] genericTypeArguments, Type[] genericMethodArguments)
   at System.Reflection.CustomAttribute.FilterCustomAttributeRecord(CustomAttributeRecord caRecord, MetadataImport scope, Assembly& lastAptcaOkAssembly, RuntimeModule decoratedModule, MetadataToken decoratedToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, Object[] attributes, IList derivedAttributes, RuntimeType& attributeType, IRuntimeMethodInfo& ctor, Boolean& ctorHasParameters, Boolean& isVarArg)
   at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeModule decoratedModule, Int32 decoratedMetadataToken, Int32 pcaCount, RuntimeType attributeFilterType, Boolean mustBeInheritable, IList derivedAttributes, Boolean isDecoratedTargetSecurityTransparent)
   at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeType type, RuntimeType caType, Boolean inherit)
   at System.Attribute.GetCustomAttributes(MemberInfo element, Boolean inherit)
   at System.Composition.TypedParts.Util.DirectAttributeContext.GetCustomAttributes(Type reflectedType, MemberInfo member)
...

At this point I'm lost. Do my binding problems look like they're related to CoreFx and the library packaging or is this really an issue with Roslyn/MSBuildWorkspace?

@daveaglick

This comment has been minimized.

Copy link

daveaglick commented Apr 11, 2017

I've gotten my problems worked out - probably not related to this issue after all.

I was using Microsoft.Extensions.Logging. That depends on NETStandard.Library 1.6.1, which in turn depends on System.Diagnostics.Tools 4.3.0. Because of this dependency chain, I was getting an automatic binding redirection to System.Diagnostics.Tools 4.0.1.0 except that version doesn't exist in the NuGet package for full framework and the version in the GAC is lower. When it tried to bind System.Diagnostics.Tools it was picking up the auto-redirect and couldn't find it since that caused it to skip the lower GAC version. Adding the following explicit redirect to my config prevented the auto-redirect and solved the problem:

<dependentAssembly>
  <assemblyIdentity name="System.Diagnostics.Tools" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.0.1.0" newVersion="4.0.0.0" />
</dependentAssembly>

Sorry for hijacking the issue!

@stephentoub

This comment has been minimized.

Copy link
Member

stephentoub commented Mar 13, 2019

@terrajobst, what are the next steps for this issue? Can it be closed?

@CZEMacLeod

This comment has been minimized.

Copy link

CZEMacLeod commented Mar 14, 2019

@stephentoub @terrajobst As far as I am concerned the package Microsoft.Composition V1.0.31 solved my issue with dependencies.

@stephentoub

This comment has been minimized.

Copy link
Member

stephentoub commented Mar 14, 2019

Thanks, @CZEMacLeod.

@terrajobst

This comment has been minimized.

Copy link
Member Author

terrajobst commented Mar 15, 2019

@terrajobst terrajobst closed this Mar 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.