@MattB-MSFT, why not to enable the following old tech from Microsoft's Jeffrey Richter: https://blogs.msdn.microsoft.com/microsoft_press/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c...:
Then add these DLLs to your Visual Studio project. For each DLL file you add, display its properties and change its “Build Action” to “Embedded Resource.” This causes the C# compiler to embed the DLL file(s) into your EXE file, and you can deploy this one EXE file. At runtime, the CLR won’t be able to find the dependent DLL assemblies, which is a problem. To fix this, when your application initializes, register a callback method with the AppDomain’s ResolveAssembly event.
It works like a charm and has zero impact on build time. There are tools like this https://github.com/Fody/Costura that make "merging" setup a single package installation step. This one use Einar Egilsson's suggestion to use module initializes to enable this tech for DLL's as well.
Unfortunately, we can't access ResolveAssembly event in Sandbox, but it works on-premise for not isolated plugins. If you can't enable this event for security reasons, you can add appropriate resolver for us and everybody win.
p.s. .NET Core 3 should support single assembly compilation, don't it? If .NET Core + Standard is our future, I guess, we can leave with ILMerge/ILRepack for a while 🙂
Hello @MattB-MSFT @BetimBeja ,
First thank you guys for you answer, it was very useful 😄
the Secret Client authentification work perfectly in Windows, but in Linux i get error :'(
Microsoft.Powerplatform.Cds.Client.Utils.CdsConnectionException: Failed to connect to Common Data Service
---> System.AggregateException: One or more errors occurred. (The request channel timed out attempting to send after 00:02:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.)
---> System.TimeoutException: The request channel timed out attempting to send after 00:02:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
---> System.TimeoutException: The HTTP request to 'https://vsmptest.crm4.dynamics.com/XRMServices/2011/Organization.svc/web?SDKClientVersion=126.96.36.199' has exceeded the allotted timeout of 00:02:00. The time allotted to this operation may have been a portion of a longer timeout.
at System.ServiceModel.Channels.HttpChannelFactory`1.HttpClientRequestChannel.HttpClientChannelAsyncRequest.SendRequestAsync(Message message, TimeoutHelper timeoutHelper)
at System.ServiceModel.Channels.RequestChannel.RequestAsync(Message message, TimeSpan timeout)
--- End of inner exception stack trace ---
Folks, we have stood up an github issues site to track issue and provide status updates for the CdsServiceClient and its surrounding bits.
Please find the site here: https://github.com/microsoft/PowerPlatform-CdsServiceClient
@BetimBeja I have forward the issue your describing over to the auth team to have a look, an Anonymous response is defiantly not what we want in this situation.
@Tounisiano that looks a lot like a network issue, are you using a Linux hosted function there? or are you hosting it on your own box?
Is there an intention of supporting additional authentication types for .NET Core before GA? We currently connect to customer's on-prem instances with and without IFDs as well as online instances, and currently the CRM SDK is the only thing holding us back from switching fully to .NET Core/Standard.
The current CrmServiceUtil generates classes that work cleanly with the .net core clients.
Insofar as building a version that will codegen based on .net core. at this time no.
Its not on our short term list as .net core is missing a good deal of the code dom we use to do mutilanguage generation in CrmServiceUtil.
That said, as .net core evolves our options may change.
Could you outline your use case for needing it?
If the generated classes work with .NET core I'm fine. I don't need a .NET core based version of the tool itself.
My use case is to communicate with CDS from an Azure Function using Web API combined with early bound classes.
As far as I can tell, the new SDK will only support connecting via Web API and not SOAP, is that correct? What is the earliest version that it will connect to - 8.0?
For on-prem IFD instances with ADFS, what authentication methods are planned to be supported?
Watch Microsoft Business Applications Summit sessions on-demand.
The time has come: We are finally able to share more details on the brand-new ranks coming to the Power Apps Community!
Features releasing from April 2020 through September 2020