I'm trying to test an ASP API controller which in turn calls out to a DLL which uses MathNet.Numerics.LinearAlgebra. I first call
MathNet.Numerics.Control.UseManaged();
However this call fails with the error
Exception thrown: 'System.NotSupportedException' in
MathNet.Numerics.dll
Additional information: Cuda Native Provider not found.
Why would Cuda be required when I'm explicitly telling MathNet to use managed not native?
It actually does not fail, the exception is handled internally. You can just continue debugging.
The exception is not actually thrown within the UseManaged call but internally at the static construction of the Control class, the first time it is being accessed and initializes the default providers (which includes probing whether any of the known native providers are available). Of course, Cuda is not required when using the managed providers.
This is indeed a small usability issue when debugging with "break on all exceptions" enabled. We may be able to avoid throwing the exception with a small refactoring. Maybe we should open a GitHub issue to track this?
Related
(If this question is poorly worded, could someone please help me clear it up?)
I have an Azure Function (2.0) which relies on some System.Drawing code. I've added a NuGet reference to System.Drawing.Common (4.5.0).
After publishing the app, however, when the function is called, it produces the error:
System.Private.CoreLib: Exception while executing function:
[MyFunctionName]. System.Drawing.Common: System.Drawing is not
supported on this platform.
As far as I'm aware, System.Drawing.Common is supported on .NET Core now, which I believe is the environment in which my Azure Function is running. The actual project is a .NET Standard 2.0 project, though.
I am confused as to how to resolve this. I've tried converting the project to a .NET Core 2.1 project but that led to bizarre errors related to "Metadata generation failed" and an inability to find System.Runtime.
My project references Microsoft.Azure.WebJobs.Extensions.EventGrid (2.0.0-beta2) if that's relevant.
It's not about the CLR, it's about the sandbox.
System.Drawing relies heavily on GDI/GDI+ to do its thing. Because of the somewhat risky nature of those APIs (large attack surface) they are restricted in the App Service sandbox.
Win32k.sys (User32/GDI32) Restrictions
For the sake of radical attack surface area reduction, the sandbox prevents almost all of the Win32k.sys APIs from being called, which practically means that most of User32/GDI32 system calls are blocked. For most applications this is not an issue since most Azure Web Apps do not require access to Windows UI functionality (they are web applications after all).
Try to find an different library that doesn't rely on System.Drawing/GDI, like ImageSharp.
A little update can help a lot of people.
Now you can switch your Azure Function to v3:
in Function app settings panel -> Runtime version ~3
With this setup, your code run in a sandbox that support Core 3, (you don't need to rebuild your dll to Core3, i run my .net core 2.1 dll without errors), and surprise... you don't get this exception anymore:
System.Drawing.Common: System.Drawing is not supported on this platform.
Because the CLI can found GDI/GDI+ that need in the subsystem.
Now i can convert html to pdf without go crazy.
I have a really awkward problem. I have build my app for iOS and tested it on all emulators and it works fine. I have installed it on a device (iPhone 6 plus) and that works fine as well. However, when I submit it to the app store, the feedback is that it crashes on launch on all devices. The crash log attached shows this error;
Unhandled Exception:
System.ExecutionEngineException: Attempting to JIT compile method 'GalaSoft.MvvmLight.Messaging.Messenger:get_Default ()' while running with --aot-only. See http://docs.xamarin.com/ios/about/limitations for more information.
The code that causes this error is in ViewWillAppear;
Messenger.Default.Register<LoggedInFailedMessage>(this, LoginFailed);
Messenger.Default.Register<LoggedInMessage>(this, LoggedIn);
The below stack overflow thread seems to indicate it might be caused by using value types, but I am using reference types.
System.ExecutionEngineException: Attempting to JIT compile method only in Debug Mode on device (MonoTouch)
Any ideas would be greatly appreciated! I don't know how I can test for these errors if they work when i debug on emulator and device but fail when apple test it.
Most of those issues where fixed a long time ago. Make sure your options for the AppStore builds (or the one you used to submit) match the one you're testing (e.g. Debug builds).
In particular make sure that the Enable generic value type sharing options is ON on the build you are submitting. This will include some extra code to ensure all value types code path variants are available at runtime.
Note that this setting should already be ON by default. Still it's a good practice to ensure your debugging/release settings are mostly (except debugging stuff) identical. Otherwise you risk testing different code, locally, than what you're submitting to the store.
I have very weird situation where I have unit test (XUnit) that try to resolve webapi controllers through Autofac ( with web api contrib).
I have a situation where If I switch my configuration in Release mode, test in x86 mode, and run my test (if debug my test then it works) it throws an exception about the fact it can't resolve the controller.
Change whatever parameters in the above configuration it then works perfectly(I am using VS2012).
I know it is very little information and can not ask for a solution, but any clue about what could have been wrong will be appreciated!
Just for the record , I was trying to look at the stack frame to extract the caller class of method. In release mode, JIT may actually optimize the call stack (kind of Tail optimization) and basically remove what I expected to find (and was able to find in debug).
I have a fairly stable server application version that's been deployed for nearly a year at dozens of customers.
One new customer recently setup the application and is getting the following error:
System.MethodAccessException: Attempt by security transparent method
[SomeMethod] to access security critical method [SomeOtherMethod]
failed.
Both SomeMethod and SomeOtherMethod are methods in assemblies that I wrote, that are built against .NET 4, and that are running inside a Windows Service. If it makes a difference, SomeOtherMethod does reference a type from a 3rd party assembly (EntLib 4.1) built against .NET 2.0. Looking at the code for EntLib 4.1, I do see that they use both SecurityTransparent and APTC attributes, but this has never caused issues at other clients.
These assemblies were upgraded from the .NET 2.0 CLR, but a long time ago. This exact code is running on other customers just fine, and I'm not explicitly using the APTC attribute nor am I using the SecurityCritical attribute anywhere.
This leads me to the conclusion that it's a configuration issue or perhaps .NET Framework patch issue. Has there been a patch released for .NET that would cause this breaking change? Is there a configuration setting some where that enforces this type of check which is off by default but that my customer may have enabled?
One last point. My service utilizes SSRS RDLCs to generate PDFs. Due to some changes in .NET 4, I must force the service to use the legacy security policy via the following config:
<runtime>
<NetFx40_LegacySecurityPolicy enabled="true" />
</runtime>
For more details on why I need to do this, see this stackoverflow post: Very High Memory Usage in .NET 4.0
The important point is that I do this at all my other customers as well. Only this one customer is having issues.
Sigh, the patterns and practices employed by the Microsoft Patterns And Practices team that's responsible for the Enterprise libraries are pretty deplorable. Well, the exception is accurate, you cannot call a method that's decorated as "I'll definitely check security" from code that's decorated with "Meh, I won't check security so don't bother burning the cpu cycles to check it". Which scales about as well as exception specifications as used in Java. CAS is incredibly useful, but diagnosing the exceptions is a major headache and often involves code that you don't own and can't fix. Big reason it got deprecated in .NET 4.
Editorial done. Taking a pot-shot at the problem, you need to find out why CAS is being enforced here. The simplest explanation for that is that the service doesn't run in full trust. The simplest explanation for that is that the client didn't install the service on the local hard drive. Or is generally running code in don't-trust-it mode even on local assemblies, a very paranoid admin could well prefer that. That needs to be configured with Caspol.exe, a tool whose command line options are as mysterious as CAS. Pot-shooting at the non-trusted location explanation, your client needs to run Caspol as shown in this blog post. Or just simply deploy the service locally so the default "I trust thee" applies.
Editing in the real reason as discovered by the OP: beware of the alternate data stream that gets added to a file when it is downloaded from an untrusted Internet or network location. The file will get a stream named "Zone.Identifier" that keeps track of where it came from with the "ZoneId" value. It is that value that overrides the trust derived from the storage location. Usually putting it in the Internet zone. Use Explorer, right-click the file and click "Unblock" to remove that stream. After you're sure you can trust the file :)
I was facing the similar issue while running the downloaded WCF sample from http://www.idesign.net/ while using their ServiceModelEx library.
I commented out the below line in AssemblyInfo.cs in ServiceModelEx project
//[assembly: AllowPartiallyTrustedCallers]
and it worked for me.
In case it helps others i post my solution for this issue:
1) On the AssemblyInfo.cs, removed/commented the [assembly: SecurityTransparent] line.
2) The Class and the Method that does the actual Job was marked as [SecuritySafeCritical], in my case establishing a Network Connection:
[SecuritySafeCritical]
public class NetworkConnection : IDisposable
{
[SecuritySafeCritical]
public NetworkConnection(string networkName, NetworkCredential credentials)
{
.............
}
}
3) The Caller Class and Method was market as [SecurityCritical]:
[SecurityCritical]
public class DBF_DAO : AbstractDAO
{
[SecurityCritical]
public bool DBF_EsAccesoExclusivo(string pTabla, ref ArrayList exepciones)
{
....
using (new NetworkConnection(DBF_PATH, readCredentials))
{
....
}
}
}
In my case it was an issue when I managed a NuGet packages in the solution some package overrides System.Web.Mvc assembly version binding in main web site project. Set back to 4.0.0.0 (I had 5.0 installed). I didn't change notice the change because Mvc v4.0 was installed and accessible via GAC. Set back
I have an App.config fiel in which i defined some binding information.
I want this information in some external file so that user can change it whenever required.
Anyone have an idea about how to implement it?
Thanks in advance
Assuming we're talking about assembly binding redirects...
The runtime is going to use your App.exe.config file to locate the binding redirects. I don't believe you can do anything about this in a normal managed application because the runtime is already initialized by the time you can run any code.
If you had an unmanaged "shim" (an exe in C++ for example) that used the CLR hosting API's, you can tell it the name of a config file to use when you set up the AppDomain. But I don't believe you can make your binding redirects separate from the main application config.
Your only other option would be to handle the AppDomain.AssemblyResolve event to handle binding failures. But this is potentially expensive as the runtime will exhaust all of its options for probing the assembly before raising this event.