according to msdn System.runtime.caching is not available to the client profile. currently this caching works for .net full.
where my application is going to be deployed only supports the client profile so retargeting is not a option.
is there a open source library that will implement this functionality / or would it be better to download system.runtime.caching project from http://referencesource.microsoft.com/#System.Runtime.Caching/System/Caching
and attempt to re implement the classes removing dependency's from the full framework is this even possible ?.
Related
I have a .NET Core 3.1 WPF app that I'm working on. In order to work with our older application it needs to validate credentials that are entered into a dialog for a local account. How can this be done?
It appears that all of the necessary classes have not been included in .NET Core yet, because the System.DirectoryServices package does not yet have the AccountManagement.PrincipalContext class that used to be used for this purpose.
Clarification
I have to validate creds for an arbitrary user account that may or may not be the account executing the app.
I hate to tell you, but the simple answer is that you can not. Interaction with active directory. There are limits on how integrated DNC 3.1 is - and you stumbled upon one. Supposedly dotnet 5.0 will better integrate.
For now, you can either use win32 / native syntax for this, or use a server side proxy that handles the authentication.
To my knowledge, you re requirements are simple not implemnented in the scope of the platform chosen.
Anyone please feel free to correct me.
Update: This is doable in .NET not core - so you can put up a smple website for this as service in .NET. So from the wpf side this turns into "make a http request".
I developed a test .NET Core Web App to which I added the .doc to .pdf conversion tool GemBox.
Their documentation for Azure deployment combined with .NET Core is limited to non-existing and their support guys could not help me with a clear solution either.
The error I get:
HTTP Error 500.31 - ANCM Failed to Find Native Dependencies Common
solutions to this issue: The specified version of
Microsoft.NetCore.App or Microsoft.AspNetCore.App was not found.
I tracked down the problem to the following issue:
GemBox.Document for .NET Core 3.0 uses WPF.
Is it possible that App Service added a limited support for WPF?
Thanks,
Lorena
The latest released version of GemBox.Document have cross-platform support for saving to PDF which doesn't have a WPF dependency, see the release post or the ASP.NET Core example.
So, you can now use GemBox.Document on Azure services, such as App Service, Azure Functions, etc. without any issue.
I built an Azure WebAPI. I did not create the project with Authentication at the time it was first created. I added Active directory Authentication based on a code sample from Microsoft. It utilizes Microsoft.IdentityModel.Clients.ActiveDirectory which I got from NuGet. It works just fine.
I then created a WebAPI from VS 2017 and selected Authentication (using AD) at the time of project creation. It included Microsoft.AspNetCore.Authentication.AzureAD.UI.
I am not sure of the difference between these two NuGet modules nor which is better suited for my Azure WebAPI.
Then comes the modules to use in a .NET WPF client. There is no AuthorizationContext class (and others) in Microsoft.AspNetCore.Authentication.AzureAD.UI. Should I stick with Microsoft.IdentityModel.Clients.ActiveDirectory in the .NET WPF client or are there equivalents in Microsoft.AspNetCore.Authentication.AzureAD.UI?
For your web api project, answer is it depends on what you're trying to do from within the web api. For most simple scenarios where you just need to read/validate tokens, you should be good with the added Microsoft.AspNetCore.Aurthentication.JwtBearer nuget pacakges. More detailed question/answer available in this SO post
In case of your WPF client application although, you won't have much choice. You will need to work with ADAL or MSAL based on which AD version/endpoints you want to use. Also, in case of WPF client more probably than not you will need to acquire a token from Azure AD so internal operations (which library will take care of under the hood e.g. authenticationContext.AcquireTokenAsync) will be a little more involved than just reading the provided token from a header and hence the package.
With the recent release of .NET Core 1.0, we're in the process of migrating our RC1 applications to the final release. The only piece we can't seem to figure out is how to integrate Active Directory authentication.
Previously in the RC1 applications, we had used the System.DirectoryServices.AccountManagement library to handle the LDAP authorization queries. However, we can no longer mix this library with .NET Core v1.
Generally, what is the best way to integrate Active Directory authentication into our applications using the libraries available for use in the .NET Core framework? IdentityServer, some other third party service like Auth0 or something else?
The Novell.LDAP library has been ported to .NET Core you can find it in NuGet. There are numerous samples available, including a verify password sample.
Best is subjective, really there's only one way right now, given the missing DirectoryServices namespace (which is planning for 1.1) - federation.
You'd have to install ADFS, and expose it to the internet. Then you configure it to act as an OAuth2 endpoint, and use the generic OAuth middleware to redirect logins to your ADFS server. You could also install the latest ADFS beta, which needs the latest Windows Server beta, and use OpenID Connect, but that's a lot of beta risks you may not find acceptable.
Or, if you just want the latest MVC pieces, run it on .NET Desktop, where you have full access to the directory services namespace.
The System.DirectoryServices namespace is currently being implemented in .NET Core, work is ongoing.
https://github.com/dotnet/corefx/issues/2089
Just want to say that they just issued a pre-release of the Microsoft.Windows.Compatibility which contains the System.DirectoryServices components needed to integrating with Active Directory
https://www.nuget.org/packages/Microsoft.Windows.Compatibility/2.0.0-preview1-25914-04
Last year someone reported encountering this problem ("The Silverlight project you are about to debug uses web services. Calls to the web service will fail unless the silverlight project is hosted in and launched from the same web project that contains the web services.") and accepted the answer to "set the web project which hosts the Silverlight application to be your startup project."
I'm seeing the same message, but think the solution might have to be different. I am building in VS 2010 a Silverlight application to access the Google Weather API, with VB as the code-behind. The API will return a XML file with data for the specified city (ex., "http://www.google.com/ig/api?weather=london,england"). The Solution Explorer only shows my VB/Silverlight project ("GetWeather"), and the Project Properties dialog box shows the Startup Object as "GetWeather.App" -- the only choice. I'm trying to use a WebClient object to make the call and an XDocument object to parse the return. But I repeatedly get the above error message, with no other result. What am I doing wrong?
Thank you in advance!
I would add a simple Web project and configure it to host the Silverlight app. You'll need to host the app somewhere anyways, so why not create a stub ASP.NET application in your solution? The easiest way is to create a new Silverlight app solution selecting an ASP.NET web project as the host, and then copying your existing code to that solution. Then you should set the web project as the startup one. This should make debugging a lot easier.
Besides, do remember to configure the client access policy to enable cross-domain calls. Check out this article