I have problem with release version of my application. After retarget windows store app to universal windows platform project i can't run application in release mode with Compile with .NET Native tool chain option checked.
I get an error:
Exception thrown: System.Reflection.MissingRuntimeArtifactException in System.Private.Reflection.Core.dll
Additional information: MakeGenericMethod() cannot create this generic method instantiation because the instantiation was not metadata-enabled: System.Linq.Enumerable.Distinct<System.Char>(System.Collections.Generic.IEnumerable<System.Char>)
For more information, please visit http://go.microsoft.com/fwlink/?LinkID=616868
When i disable Compile with .NET Native tool chain application is working and doesn't throw a exception.
Generally this is solution, but in Windows App Certification Kit i get failed result with errors (Test Supported API):
·API ExecuteAssembly in uwphost.dll is not supported for this application type. App.exe calls this API.
·API DllGetActivationFactory in uwphost.dll is not supported for this application type. App.exe has an export that forwards to this API.
·API OpenSemaphore in ap-ms-win-core-synch-11-1-0.dll is not supported for this application type. System.Threading.dll calls this API.
·API CreateSemaphore in api-ms-win-core-kernel32-legacy-11-1-0.dll is not supported for this application type. System.Threading.dll calls this API.
Someone can help?
The .NET Native runtime doesn't include a JIT compiler. As a result, all necessary native code must be generated in advance. A set of heuristics is used to determine what code should be generated, but these heuristics cannot cover all possible metaprogramming scenarios. Therefore, you must provide hints for these metaprogramming scenarios by using runtime directives. If the necessary metadata or implementation code is not available at runtime, your app throws a MissingMetadataException, MissingRuntimeArtifactException, or MissingInteropDataException exception. Two troubleshooters are available that will generate the appropriate entry for your runtime directives file that eliminates the exception:
The MissingMetadataException troubleshooter for types.
The MissingMetadataException troubleshooter for methods.
See here: https://msdn.microsoft.com/en-us/Library/dn600640%28v=vs.110%29.aspx
Related
The exception code C0000005 is thrown from mscorwks.dll when the application is run on Windows Server 2008 R2 launched using test complete. Other platforms (Windows XP, Server 2003 R2, Windows 7 32-bit and 64-bit) do not present this exception.
The event log from a single execution has many of the following event with event ID 1023 raised by the .NET Runtime:
.NET Runtime version 2.0.50727.4952 - Fatal Execution Engine Error (7383851A) (80131506)
The application itself makes use of a SOAP interface generated by Visual Studio from a WSDL file, a COM object with an embedded interop, and is targeting .NET 4.
sfc /scannow was run and found no problems with system files on the affected system.
What troubleshooting can be done to identify a solution?
Fatal Engine Execution Error and an access violation are both symptoms of the same problem. FEEE is raised when the .NET garbage collector detects that the internal structure of the garbage collected heap is destroyed. An access violation is a hardware exception, raised by the processor when it is asked to access memory with an invalid address. A common cause of an AV is heap corruption.
These kind of mishaps are very commonly caused by unmanaged code. It is also quite common for unmanaged code to have latent memory management bugs that can go unnoticed for a long time. The kind of damage the bug can do tends to be quite random. Just running it on another operating system which has a different memory allocation pattern can be enough to trigger the bomb.
You have an excellent candidate for the source of the trouble. You'll need to work with the COM server vendor or author to chase the bug.
A 0xC0000005 is an exception code wrapping a Win32 error which means "Access Denied." Given that you are using COM interop and are getting an ExecutionEngineException (in COM, COR_E_EXECUTIONENGINE; 0x80131506), my guess is that either it's a NULL pointer in the COM component or a faulty ComImport directive in your .NET code.
This error is caused by flaws in the way that TestComplete 7 interacts with the heap in mixed managed/unmanaged applications. Instead of using the TestedApp.Run method using the following block of code, modified for you choice of scripting language, presented in VBScript:
Dim oScript, command
Set oScript = CreateObject("WScript.Shell")
command = "%comspec% /c " & PATH_TO_EXE & " " & Args
oScript.Run command, 10, True
The relevant MSDN article is Run Method (Windows Script Host).
TestComplete 7 (including the latest update 7.52) supports .NET Framework 4 only up to version .NET 4 Beta 2. It does not support the release version of the Framework, so this may be the reason of the problem.
Try building the application targeting .NET 2.0. This should resolve the problem.
To test .NET 4 applications, you will need to use TestComplete 8.
I am creating an Azure Function in C# using a target framework of netstandard2.0 in a Windows 10 environment. The function calls a method that's in another class library and that method creates an instance of SqlConnection. When I run the function I get the following exception:
Microsoft.Azure.WebJobs.Host.FunctionInvocationException : Exception
while executing function: Functions.RefreshImages --->
System.Reflection.TargetInvocationException : Exception has been
thrown by the target of an invocation. --->
System.PlatformNotSupportedException : System.Data.SqlClient is not
supported on this platform. at
System.Data.SqlClient.SqlConnection..ctor(String connectionString)......
Obviously SqlConnection is supported on Windows so I assume there's something else going on here.
This happens when a .Net Standard lib that uses a SqlConnection is loaded dynamically via reflection. The .Net Standard lib will typically reference System.Data.SqlClient which seems to be a dummy lib without actual implementation. It apparently ensures that the lib will compile on all platforms, including those without Registry and other platform specific stuff that the real SqlClient implementation relies on.
The easiest solution I can find is to add a reference to the Microsoft.Data.SqlClient NuGet package in the host application (the .Net core application that dynamically loads the .Net standard lib).
You may see a small yellow warning exclamation icon in the Solution explorer because Visual Studio thinks you are not using the lib and if you use the "Remove Unused References" feature it will also suggest removing the package. There is a feature to suppress warnings in the PropertyGrid, but I cannot figure out wat number should be filled in since the warning does not appear in the error list when compiling...
It looks like this is related to loading a SQL connection via reflection in .NET core (you are running on netstandard2.0 but the principle should still be the same).
I'm working on a Windows 10 Store Windows Universal app using Visual Studio 2015 Community, c#, and XAML. It is decompressing a compressed file and displaying images found therein.
The build provides 0 warnings.
The debug version runs fine regardless of input file size.
The release version runs fine with typical input file sizes.
For large input file sizes (~100 1 megapixel images), the release build crashes consistently with 'Unhandled exception at 0x55E9A305 (Windows.UI.Xaml.dll) in appname.exe: 0xC000027B: An application-internal exception has occurred (parameters: 0x127DC468, 0x00000005).'
The crash occurs when the user tries to display the second image. All decompression is complete and all the bitmaps have been created by this time.
I've fiddled with the Build settings and narrowed down the difference to the option 'Compile with .NET Native Tool chain'. If that option is checked, the application crashes. If that option is unchecked, the application runs fine.
All told, the application is using about 400 MB of heap so although not small it isn't near the capacity of the machine.
"So uncheck the option!", I hear you cry. Unchecking the box leads to the certification failure shown below:
FAILED
Supported APIs
• Error Found: The supported APIs test detected the following errors:
-API OpenSemaphore in api-ms-win-core-synch-l1-1-0.dll is not supported for this application type. System.Threading.dll calls this API.
-API CreateSemaphore in api-ms-win-core-kernel32-legacy-l1-1-0.dll is not supported for this application type. System.Threading.dll calls this API.
-API ExecuteAssembly in uwphost.dll is not supported for this application type. StupidTest.exe calls this API.
-API DllGetActivationFactory in uwphost.dll is not supported for this application type. StupidTest.exe has an export that forwards to this API.
An empty project suffers the same failure if Compile .Net Native tool chain is not selected.
So my questions:
Must Universal Apps use Compile .Net Native tool chain?
Is there any documentation on the meanings of the parameters in the internal exception or somewhere else I can turn to troubleshoot?
In short, any advice on getting out the "It doesn't work if selected, but you must select it to get certified" dilemma I find myself in?
I struggled with this issue also for the past few days, and I've found the answer!
So if you haven't updated Visual Studio 2015 to Update 1, do it. Because this error is a bug in the compiler and after the update you will be able to build the project with the Compile .Net Native tool chain option selected.
And yes, those four errors that the WACK tool picks up, is because of compiling your project without checking the .Net Native tool chain option in the Build menu of the Package.appxmanifest file.
I have a such code (It's a part of unit tests executed by nunit-console):
class MyClass
{
[DI(Type = typeof(MyClass))]
public IMyClass MyClassProperty {get;set;}
}
By reflection i'm scanning such classes and then register in Autofac:
// Register MyClass as IMyClass
autofacBuilder.RegisterType(diAttribute.Type).As(propertyInfo.PropertyType);
After that i need to resolve this property in the same way - by reflection:
autofacContainer.Resolve(propertyInfo.PropertyType) // it contains IMyClass
When I'm launching this code locally it works well.
But doesn't work on TeamCity. Fails with error:
Error: 'Autofac.Core.DependencyResolutionException: An exception was thrown while executing a resolve operation. See the InnerException for details. ---> Common Language Runtime detected an invalid program. (See inner exception for details.) ---> System.InvalidProgramException: Common Language Runtime detected an invalid program.
There are a lot of questions on StackOverflow about this exception. It's not an Autofac problem, it's a JIT compiler problem. A quick Google search on the exception yields a lot of info.
InvalidProgramException / Common Language Runtime detected an invalid program
Common Language Runtime detected an invalid program?
You even see projects like NewtonSoft.Json running into the issue.
The exception itself means "a program contains invalid Microsoft intermediate language (MSIL) or metadata; generally this indicates a bug in the compiler that generated the program."
Microsoft has a KB article on troubleshooting the issue. Whenever folks have resolved it, as far as I've seen, it's always one of two fixes:
A change to the compilation options. For example, some people running encryption/obfuscation sorts of tools find turning them off helps; others find turning off compiler optimization fixes it. (The KB article has some tips.)
Making sure things are patched to the latest versions. I've run into other similar situations myself where things work great on my machine but not on the build server; or vice versa. Almost invariably it's because I have my machine all patched up but the build server has been languishing unpatched; or someone just patched up the build server and I haven't installed my patches yet.
I'd recommend starting with the patches since that's usually the simplest fix. Use Windows Update to make sure both you and the build server have the latest .NET updates. If that doesn't fix it, check out some of the troubleshooting tips in the articles and questions above.
My problem begins with moving a .Net 2.0 application to .Net 4.0. The reason I had to do this was that Windows 8 does not enable the earlier .Net versions by default and my application cannot ask the user to enable it.
The application is a NPAPI plugin which uses .Net components via UnmanagedExports. I designed it as a low integrity application and therefore it has to reside in the users 'LocalLow' directory.
In my application I used a dynamic assembly loading mechanism to load several assemblies at runtime. I used the following method to load an assembly,
MyInterface Instance;
Assembly assembly = Assembly.LoadFrom(AssemblyFile);
Type type = assembly.GetType(Identifier); // Identifier is implementing the MyInterface
Instance = Activator.CreateInstance(type) as MyInterface;
// Do something with the Instance
After modifying the project to .Net 4.0, I noticed that the plugin crashes when the binaries are placed inside the LocalLow directory (It works in other places). My next step was to create a minimalistic plugin with least possible code to figure out the issue. I noticed that the dynamic assembly loading failed with the following exception,
System.IO.FileLoadException: Could not load file or assembly '<assemblyPath>' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515 (COR_E_NOTSUPPORTED)) --->
System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=131738 for more information.
I tried the following approaches to create a separate domain and load the assemblies but with no luck,
http://blogs.msdn.com/b/shawnfa/archive/2009/06/08/more-implicit-uses-of-cas-policy-loadfromremotesources.aspx
http://www.west-wind.com/weblog/posts/2009/Jan/19/Assembly-Loading-across-AppDomains
Adding the configuration 'loadFromRemoteSources' did not work either. It seems that the .Net component does not load .dll.config files. (Could be because of UnmanagedExporting)
My questions are,
Is it possible to dynamically load an assembly from LocalLow?
Does the new CAS policy in CLR 4.0 apply to LocalLow as well? From what I understood so far it should affect only assemblies loaded over the network
Is there any other way to overcome this issue?
While it doesn't address your LocalLow issue specifically, if you are able to "read a file" from the directory, you might be able to use the "work around" detailed here:
How can I get LabView to stop locking my .NET DLL?