System.DirectoryServices conflicts with what ships in .NET Framework

[weshaggard]

We need to rename System.DirectoryServices library because we already have an assembly with that identity that ship in .NET Framework. We need a new name for that library before we can ship it.

[weshaggard]

Similar for System.DirectoryServices.Protocols and System.DirectoryServices.AccountManagement.

We cannot use the same assembly identities unless we expect them to always contain the exact set of APIs.

[danmoseley]

@weshaggard can we point to an example or otherwise explain what's required so code owners can easily do this?

Leaving in future as I'm not sure of our ship plans for this for 2.0. @karelz

[weshaggard]

For new libraries there name should get reviewed via the api-review process to ensure that we have consistent names and no conflicts with existing shipped libraries. So for this case the owners need to propose some new assembly names that don't conflict, or a plan that explains why the conflict will not be an issue.

[karelz]

It sounds like we should decide on this before we ship preview build -- which is 2.0 timeframe :)
Moving to 2.0 then (@weshaggard can you please confirm it is must have before first preview on nuget of the package?)

[weshaggard]

We don't currently build these packages (dotnet/corefx@715263f) so they won't get shipped with preview.

[karelz]

OK, Future if we don't build it.
We can always ship ad-hoc preview (aka push it to nuget.org) when we are ready and there is interest from community.

[Petermarcu]

How do we want to track something that we want to preview on the 2.0 timeframe. We should finish the assembly naming conversation, make the package, and get a preview out ASAP.

[karelz]

@tquerec @jay98014 can you please help us get unblocked to ship the binary as preview?

[weshaggard]

If we want to ship a preview of this package I would suggest we do it from master and not in release/2.0.0 branch as trying to keep things correctly segregated in release/2.0.0 will be more risk then just doing this one-off from master itself.

[ericstj]

@Petermarcu has asked me to enable this.

Suggestion is to just append .Core to the assembly names.

Here's another suggestion.
System.DirectoryServices -> System.DirectoryServices.Primitives
System.DirectoryServices.AccountManagement -> System.DirectoryServices.Accounts
System.DirectoryServices.Protocols -> System.DirectoryServices.Extensions

/cc @terrajobst for FXDC/Naming

[weshaggard]

We should avoid just using ".Core" suffix as that is not a pattern we want to use for these namings. We generally try to name them based on the contents of the library. @ericstj while your suggestions seem reasonable I think we need some input from the owner of these to provide some feedback to ensure they align with the technology they provide.

[ericstj]

Is there any objection to just putting them in place temporarily so that we can build the packages and let folks try them out? @jay98014 what do you think?

[ericstj]

@terrajobst and I looked at this and decided to keep the same name as desktop and make them match / be a pure subset of what's in desktop. This keeps the the compat/shim story simple for using these on NS2.0 and is inline with the level of churn we expect to see in these assemblies (little to none). I think this is considerably different from the ConfigurationManager case because we aren't trying to do any assembly refactoring as part of this work. Its a pure port.

I'll add some comments to the projects that they can't add API to these assemblies as they are meant to match desktop 1:1. They'll have to follow the same constraints as stuff in NETStandard.

There are a few issues (removed abstract members) that we need to fix in order to make this work. I'll file an issue on that.

[weshaggard]

Sounds reasonable for now and we can always split them later if we want.

[weshaggard]

I'll add some comments to the projects that they can't add API to these assemblies as they are meant to match desktop 1:1

We should see if we can add some apicompat checks to help ensure this. Perhaps we should do that for anything where we place a placeholder in the netfx folder in the package.

[NickJosevski]

@weshaggard @karelz has a decision made on the assembly names to avoid the conflict?

If the preview packages are still not ready to release, could you give some guidance on which branch is close to what will end up in the preview packages, I can build from that, and just hosts them for myself on myget for now...

I'm eager to start using a preview release of these assemblies, as it will allow me to continue building against netstandard 2.0 and support directory services for something that just needs to run on Windows for now.

[ericstj]

Yeah, I'll have a fix in today and you can expect packages from master by tomorrow morning.

[xaviergxf]

Hi, Can i use this package with vs 15.7.1? I've added the nuget packages 4.5.0-rc1 but it mixes with the one on the gac. Should this nuget package produce dll's on my bind/net471 folder?

Thanks

[karelz]

@xaviergxf can you please file a new issue? Closed issues are not monitored.
Please post repro showing what kind of "mix" happens for you.