I am trying to write a library in ASPNET5 Core using VS2015 CTP6 that calls the Azure Service Management REST API. The code works fine in a .NET45 Console App.
In an ASPNET5Core Console App, the code fails silently on the AcquireTokenAsync call and the program terminates.
In an ASPNET5 Console App, the program won't even build with errors stating I must add a reference to System.Threading.Tasks and System.Runtime.
You can find a repo containing all three projects here:
https://github.com/npnelson/ADALSamples.git (make sure you read the readme on the repo for more information)
Are these bugs, or am I missing something?
The .NET Core support in the current ADAL Alpha is provided only for confidential client flows, that is - code behind of web applications and processes running on the server. Native clients on .NET core are not supported.
Related
I have a .NET Core 3.1 API calling wkhtmltopdf.exe to generate a PDF (using RotativaCore wrapper).
Its working fine with moderate usage... The problem when I have too many request at same time ...
Several 'wkhtmltopdf.exe" will stuck on Windows processes and I start to get several errors:
QEventDispatcher: Failed to create QEventDispatcherWin32 internal window: 87 Qt: INTERNALL ERROR: failed to install GetMessage hook This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
How can I handle that?
I have a MVC project solution and a separate API project solution (because it is used by different other solutions).
During debugging is it possible to hit the API solution code on debugging?
Both solutions are obviously running, giving correct data and results, the issue is that I am unable to hit the API project code during debugging - the debugger skips over the API and hits only the main solution.
EDIT
I realised that the API is a separate package and is referenced in the main solution as an assembly so I am not sure if it is possible to hit the breakpoint there at all? It's not used via Ajax.
yeah it is possible.
Assuming you use Visual Studio, start a second instance and attach it to the running process of the API. Put a breakpoint in your API and do whatever you need on the MVC side, to hit the correct endpoint in the API. Execution will stop and you can now debug in the second project as well.
This all depends how you run the API, you can even run the API from Visual Studio, using IIS Express in which case your URL will look something like http:\\localhost\api\sbla\bla:50310 for example.
Attaching works very well when the API is run outside of Visual Studio in proper IIS.
Make sure you tick the box which says "Show all processes" and look for a process called w3wp I think, this is all from memory.
You can't debug the API from the MVC project as they are both running under different processes
------ added after extra info ----
if the API stuff is inside a dll then make sure that dll is built in debug mode and then you can step into it. put a break point inside your MVC code right before you have a call which goes into the dll, then step into it and continue from there with normal debugging
Yes, it is possible.
Just open both your solutions in visual studio. Build the API project and add its dll to MVC project. Put break point on your API and run the API project. Now run your MVC project. Hit the API from your MVC project and break point will surely hit in API.
I have a web app (.Net 4.6.2) running on an Azure App Service with Application Insights. I'm using SQL Azure as a back end. When Application Insights logs sql dependencies, the command text isn't included, just the server name and the database name shows up under 'Command'
I've uninstalled and reinstalled the extension and seem to have exhausted online sources. Can anybody suggest where else I look for a solution?
Is this how you install the extension? (Just double checking) And you tried removing/adding back the extension?
Also - does you application refer to SDK in source code already? (via nuget)
I am trying to install a privileged helper tool to perform some elevated work. I am using SMJobBless for the same.
I am able to install the tool fine and also able to communicate with it. I am using Mac OS X 10.8.4 and using NSXPCConnection for the same.
I have added .mach service in the plist which will be installed in /Library/LaunchDaemons. I am using [initWithMachServiceName:options:] in the app as the helper is privileged tool and [– initWithMachServiceName:] in the helper to listen. The communication is working fine.
But the problem is I tried the same communication with another application I created which did not have any codesign at all (the helper tool installer earlier was codesigned). I tried to connect to the mach service of the helper tool and was able to connect easily. This is a problem because anybody can communicate with it then and make it do anything.
I wanted some way to securely communicate between my application and the helper tool.
Thanks a lot.
As you've said that you're not signing the second app, I believe that that is the problem that is allowing a 2nd app from calling the helper application. From the Apple docs and specifically the ReadMe file in SMJobBless, it states: -
The Service Management framework uses code signatures to ensure that the helper tool is the one expected to be run by the main application
This document should be able to assist you in getting the helper app correctly associated with its owner.
Note that it references a python script, which is provided here.
Answering my own question: I had logged a radar bug for the same and Apple said that the behavior was intended:
"It is up to the privileged helper to not expose insecure operations"
I am running on SP1 beta of 2010... it may or may not related to the beta. But, in general, can adding a project to the codeplex TFS server somehow make WCF break when also inside an Azure project?
Seems to be the pattern for me. Immediately upon launch I get a ServicePoint exception. If I remove the app from source control everything works fine.
My project consists of
Azure WCF hello world application
VS2010 SP1 beta
Adding codeplex TFS reference causes exception
Is it a CommunicationFaultedException? If it is, it is a bug when working with Azure 1.3 SDK projects that are checked into TFS. Make sure you have the Web.config file checked out (writeable).
If not, can you give any other information on on the ServicePoint execption?