I am writing a console app in .net core which is using Microsoft.IdentityModel.Clients.ActiveDirectory for user authentication.
The nuget package contains two files in lib\netcore45 folder:
Microsoft.IdentityModel.Clients.ActiveDirectory.dll
Microsoft.IdentityModel.Clients.ActiveDirectory.Platform.dll
In the code I am trying to call the AcquireTokenAsync overload with the PlatformParameters object:
public async Task<AuthenticationResult> AcquireTokenAsync(string resource, string clientId, Uri redirectUri, IPlatformParameters parameters)
The implementation of IPlatformParameters is defined in assembly Microsoft.IdentityModel.Clients.ActiveDirectory.Platform.dll.
How should this assembly be referenced from .net core? The project.json file does not seem to allow picking a specific file from a nuget package...
Or is there another way to consume ActiveDirectory libraries in .net core?
Netcore45 targets UWP. Nuget should automatically pull the dlls as needed for each target type.
Related
I created Enterprise WSDL from SFDC and saved it on local machine.
When I add a web reference in VS 2008 it just add a reference to wsdl it does not generate a stub code ( code class) I also tried by using 'Add Service Reference' and 'Add Service Reference'--> Advanced --> Add Web Reference.
Can you please comment on this, what I am missing and How I can generate a C# code from Enterprise WSDL.
Thanks.
Your question are not clear enought. After adding a web reference, u should be abe to call it just by typing the namespace/reference. Something like var service = new EnterpriseWSDL.SforceService(); If u are having trouble to add the web reference to the project, try to put the .wsdl on c:\inetpub\wwwroot besides the project folder.
please put your local wsdl service physical path
like as
Add Service Reference'--> Advanced --> Add Web Reference-->C:\ramki\test.wsdl
I have a library that I have created that depends on EF Codefirst for DB interaction. I am also using EntityMigrations Alpha 3. When I use the library in my main application (WPF) everything works fine and as expected. Another part of the system uses Excel and retrieves information using the same library via an additional COM class in between.
In the Excel scenario, as soon as it tries to connect to the database, it throws up an exception to do with "The Provider did not return a ProviderManifestToken".
I'm really not sure why I'm only getting the error when I go through Excel/COM. In both scenarios I can confirm that the same DB connection string is being used. THe method to retrieve the DB Connection string is also the same - they use a shared config file & loader class.
Any suggestions welcome.
Issue resolved.
I had also created a custom DBIntializer and part of the intialization calls upon EntityMigrations to ensure the DB is up to date. The custom migration calls the default constructor on your context. By convention this will either dynamically use it's own connection string for SQLExpress(I don't have installed) or try to look for an entry in your config file (I don't have this either for the dll - config comes from hosting apps).
This is what is causing the failure when being used from Excel(In my scenario). The Migration will be newing up an instance of the context using the default constructor. This means that a config entry for the connection string is required or it uses the default process(SQLExpress). When being used from Excel in a COM env – no config file exists.
Moving the migration out of the Initialization strategy means I no longer have a problem.
I'm working on an asp.net application. I have a Domain assembly (containing mostly command and queries code), a Domain.Contract assembly ( containing mostly the domain objets), a Repository (called by the Domain) and the Web site.
For some specific backoffice needs, I want to create a Lightswitch application. I want to use my current domain as a datasource. I added a WCF Ria Service class Library, and in the RiaService.Web project, added a class based on DomainService, with one query method. Nothing more (no entities, since they are in my Domain.Contract assembly)
Using help from here (thanks Michael W), I was able to add the datasource, and to get my domain object recognized as an entity in light switch.
But, I now have a compile error : 'The type or namespace name 'MyDomain' could not be found in the global namespace (are you missing an assembly reference?)' in the project ServerGenerated.
The specific error is on this line :
global::Domain.Contract.MyObject result = new global::Domain.Contract.MyObject();
which is on of my domain objects (created in my Domain.Contract assembly).
So, it seems that the only thing I need to do is to add a reference do Domain.contract to the ServerGenerated project.
But it does not appear in Visual Studio. Adding my reference to the Server project does not fix the error.
Thanks.
In your solution explorer windows, select the ServerGenerated assembly and click on the "show all files" button. This will show all hidden folders - including the generated client code for WCF Ria.
If there's no generated code this means there's either something wrong with the service implementation (typically you'd get a compilation error) or there's something else wrong with the service - like a missing [EnableClientAccess] attribute (I know for a fact that a service without this attribute does not generate client code).
Other things to check for is to include the server-side ria assembly in your host project + have a correct configuration for WCF ria in the .config file (ask google).
In your solution explorer windows, select the project and click on the "show all files" button and also select the "file view" (not the logical view).
Then add the reference to the projet "ServerGenerated" (not the server project)
I am creating a Host SL app that will serve up several "Plugins" Each of these plugins can reference their own WCF service. When i import these into the Host app using MEF it says it cant find the endpoint.
What is the best way to handle these endpoints. I am trying not to have to handcode each endpoint everytime we need to release a new plugin
Using these two line below allowed me to use that service reference without the config file exporting
Private binding As New BasicHttpBinding(BasicHttpSecurityMode.TransportCredentialOnly)
Private WithEvents _Misc As Service_Misc.Misc_CallsClient = New Misc_CallsClient(binding, New EndpointAddress("http://localhost:61928/Misc_Calls.svc"))
I have created a WPF browser application that I wish to connect to a WCF service. The service is in the same solution as the WPF application. It is the default service that Visual Studio creates with a method called GetData (int)
I am attempting to call this service with the following code:
var client = new Service1.Service1Client();
client.GetData(10);
I get the following error on the above line (client.GetData(10);)
{"Request for the permission of type 'System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."}
Please help
This solution from Scott Lanford worked for me:
http://www.codeexperiment.com/post/Debugging-XBAPWCF-Applications.aspx
Quote:
The possible reasons for this error are numerous but in this case it was because the default Debug->Start Action for an XBAP project is "Start browser in URL", where the URL simply points to the .xbap file on disk (e.g. C:\projects\myproject\bin\debug\myproject.xbap).
For a partial trust XBAP application to communicate with a WCF service it must be deployed from the same domain and port as the WCF service. The way to solve this dilemma is to fake the XBAP URL by starting the XBAP application with PresentationHost.exe and supplying the XBAP URL (copied from the "Start browser with URL" value) via the debug parameter and the WCF service URL via the debugSecurityZoneURL parameter.
For example the debugging options for your XBAP project should look something like this:
Start Action -> Start external program = %windir%\system32\PresentationHost.exe
Start Options -> Command line arguments = -debug "c:\projects\myproject\bin\debug\MyProject.xbap" -debugSecurityZoneUrl "http://localhost:2022"
You need to setup a client access policy on the server. Running in the browser comes with a bunch of security limitations.
I think this article should get you the information you need, http://www.dotnetcurry.com/ShowArticle.aspx?ID=208&AspxAutoDetectCookieSupport=1.