Incompatible implementation of the WCF with Microsoft's System Center products.

[antonGritsenko]

Describe the bug This is re-created from the issue #4996, the comment from @mconnew explained it "why", but it didn't solve the problem. Yes, the WCF team did a huge mistake during implementation of the WCF in .net (core). But what next? Why you just closed the bug if it purely related to your products? It so hard to check with different department what they are doing?

There are tons of 3d party products with .net (core) developed for Microsoft System Center Operations Manager (OpsMgr) and Microsoft System Center Service Manager (SCSM). Both products are supported by MSFT, WCF is also supported by the Microsoft. Sorry, but the fact that you can't even did an internal agreement is your problem, not by your customers.

The actual problem, that all customers who want to use 3d party apps for OpsMgr and SCSM are stuck on .net core 2.x (and who trusted to Microsoft that .net core is the new future). This is last release of the .net core that support the real WCF. But the .net core 2.x is out of support, and now this is potentially huge security hole for many customers (you can call to your colleagues and ask how many System Center customers you have, trust me, around 40% of them using 3d party application, for SCSM this number is about 100%).

From my point of view, this situation is unacceptable. You leave many enterprise customers are unprotected just because of yours very wrong architectural decisions during the WCF migration. You must provide at least a workaround.

To Reproduce Add reference to Microsoft.EnterpriseManagement.Core.dll (part of the SDK for System Center Operations Manager or Service Manager) Add nuget packages System.ServiceModel.Primitives, System.ServiceModel.Duplex and System.Configuration.ConfigurationManager. Create connection:

var connection = new ManagementGroup("localhost"); // for OpsMgr
// or
var connection = new EnterpriseManagementGroup("localhost"); // for SCSM

You will get exception:

System.MissingMethodException
  Message=Method not found: 'Void System.ServiceModel.EndpointAddress..ctor(System.Uri, System.ServiceModel.EndpointIdentity, System.ServiceModel.Channels.AddressHeaderCollection)'.
  Source=Microsoft.EnterpriseManagement.Core

Expected behavior Everything works.

[mconnew]

As mentioned in the other issue, there are multiple features which are missing in WCF Client which SCOM would need. If we could release all those features tomorrow, it still would not unblock you as the SCOM SDK assembly is still implementing methods which are service api's only. As this project is also intended to be used on mobile clients, and has been scoped for client usage only, it's not appropriate to be adding service side api's. It has a transitive effect where each api we add pulls in more apis until we end up with a very large api surface area which can't have an implementation and can only throw when used. This would have the effect that someone might spend a lot of time migrating their code presuming it will work because the api's are there, only to find it doesn't work once they have fixed all the problems in their own codebase like missing dependencies etc.

The architectural decision that was made was that when possible try and only expose api's which will be functional so that the viability of porting code can be easily determined early on in a potential migration project. We emphasized fail early over only finding out there's missing functionality after lots of time and effort has been put in. Our intention is to avoid lots of wasted effort by developers.

We need to take a pragmatic approach to solving your problem. You need a library to communicate with SCOM from .NET [Core] that you can consume. The only way that's possible is if the SCOM SDK library is recompiled (with some small code changes like removing service side code) for a currently supported .NET version (so 6+). This will require the Microsoft team that owns SCOM to release this. What has happened multiple times already is internal teams have come to us and asked for the missing features they need in order to run on .NET. Our priority is to work on developing/migrating missing features for libraries actively migrating or planning to migrate to .NET.

I suggest contacting your Microsoft support contact for SCOM with the ask that an SCOM SDK library be developed/released which runs on .NET. They will take this request along with other customer requests into consideration when deciding their development roadmap (just like any team would). Only if/when that team decides they are going to do this and comes to us to ask for these missing features does it make sense for us to implement the specific missing features required.

I'm going to close this issue too as until there is a need for WCF Client development to unblock a migration, there is nothing to do. The lack of a .NET implementation of the SCOM SDK is the blocking issue.