1

We have a dozen of Asp.Net/WCF applications that we would like to migrate to SDK style. All of them use PackageReference, so that is not a problem.

We do not want to develop our own dotnet build SDK and we are not in a position to migrate to Asp.Net Core/gRPC.

This question is a follow up to Is it possible to use the Microsoft.NET.GenerateAssemblyInfo.targets with a non Sdk style project? - at the end of the day we were able to migrate most of the projects to SDK style and now we want to migrate the WCF/Asp.Net ones.

EDIT

I would like to elaborate on the expectations from such an SDK. As far as I understand, a WCF/Asp.Net project has a few features that have to be addressed:

  1. The publishing logic implemented in Microsoft.WebApplication.targets
  2. The default recognition of certain file extensions. For example, **\.html, **\.css, **\.js should be automatically included as Content, just like in the regular SDK **\.resx are automatically recognized as EmbeddedResource.
  3. Certain assembly references could be added automatically, but this is not a big deal.

Just handling these items would make our day.

mark
  • 59,016
  • 79
  • 296
  • 580
  • Nobody including Microsoft and you want to develop the required SDK, then I wonder who else is willing to spend the resources for that. – Lex Li Jan 14 '22 at 21:27
  • I do not know about that. After all, somebody did develop dotnet build SDK for Silverlight - https://github.com/novotnyllc/MSBuildSdkExtras – mark Jan 14 '22 at 22:13
  • That repo you pointed to works in a much different way (primarily for class libraries), so you shouldn't expect some simple changes can make huge stacks like ASP.NET 4.x/WCF work the same way. – Lex Li Jan 14 '22 at 22:23
  • Please, see the **EDIT** - I must be misunderstanding the complexity. – mark Jan 14 '22 at 22:36

1 Answers1

0

If I understand your question correctly..

If you are in position to package your SDK as a new .NET Core dlls / packages while keeping all existing WCF as they are, you could:

  1. Create .NET Core SDK project
  2. Add WCF service references to your SDK project
  3. Allow Visual Studio to generate proxy code
  4. Code against your WCF from the .NET Core calling your services via proxy objects generated

Here is Microsoft team's guidance:

https://learn.microsoft.com/en-us/dotnet/core/additional-tools/wcf-web-service-reference-guide

dbCoder
  • 114
  • 5
  • I added slightly the question - prefixed SDK with "dotnet build". In your answer you are talking about consuming WCF service from a .NET Core project. I am talking about migrating our WCF service/Asp.Net projects to SDK style. – mark Jan 14 '22 at 19:43
  • Understood. in the absence of option to migrate wrapping your services with proxy classes may be the next best thing – dbCoder Jan 14 '22 at 20:35