In my VS2017 solution, I created a UWP and .NET Standard Library 2.0.3 projects. Referenced Library project from UWP. Library project is using a System.Diagnostics.Process to start a process. In debug mode, I get access denied error at line Process.Start(...) of the code inside Library project.
I thought the purpose of new .NET Standard Library project was to support various platforms (.NET, .NET Core, UWP etc) uniformly. But I guess, the sandbox nature of UWP apps is probably not allowing me to run Process.Start(...) albeit the process is running inside Library project. Question: What I may be missing and/or how can we resolve the above issue?
You cannot launch process directly from UWP, but there are some alternative ways to do that. The first one is using FullTrustProcessLauncher, if you need some example, check this post series. Another way is using a WPF or WinForms application to host UWP Controls with the Xaml Islands where there aren't restrictions to call any .NET APIs, but remember, through this way, your app will work only on Desktop devices.
According to this answer, you can't use Process.Start in a UWP app. There are some alternatives for launching other apps, but you can't execute arbitrary .exe or other processes.
So I was working on a project that needs a .net 3.5 framework API. So since I can't use the API directly I decided to use communication using a bridge between a UWP/WPF app in order to use the API.
Now I have followed the steps in here: https://mtaulty.com/2016/10/12/windows-10-1607-uwp-apps-packaged-with-companion-desktop-apps/
So when launching the app from the exe directly it would work fine. However if I am to launch it it is unable to load the API.
Any idea of what I can do to deal with it? Or is there a better way to implement a .net 3.5 api in UWP?
Why does FullTrustLauncher stop the app from working correctly? Would packaging the APP in something like ILMerge help?
Or are there any ideas I can do to deal with this issue?
Edit: here is the sdk I have been using with its documentation
http://sdk.emiratesid.ae/page/Downloads.aspx
It also contains sample projects in forms however as mention the issues arise when porting to uwp
I work for a team that currently specializes in creating windows desktop applications in C#/.NET that interwork with local user instances of Microsoft Excel via Office COM Interop. I am currently charged with specifying a new product but I’ve been told that the project will not go ahead unless the app can run on Mac as well as Windows – that is, we have to be able to produce a Mac version of the app that can install natively on OSX and interact with the object model of a user’s instance of Microsoft Excel for Mac.
Running the app with Parallels, Mono or Wine (see COM Interop Through Wine in OSX, which was never answered) is not a solution because the spec for the app requires that the user machine is not modified in any way. We just have to assume the user has a licenced local copy of Excel running, and work with that… which is what we have always done on Windows, where it works great.
I think .NET Core is the answer but I can’t find anywhere where it says definitely that we can (or will be able to) access the Excel Object Library from C# when running .NET Core on Mac OSX with a local copy of Excel for Mac installed. Can anybody point me please to where this has been discussed already; but if not, then tell me how I can go about finding out from Microsoft if this is in their roadmap for .NET Core?
I have received some helpful feedback from a similarly worded question on MSDN. I have also posted an issue on the .NET Core Github, but I think it is already clear what the answer is to this, which is as follows:
The .NET Core team may perhaps be persuadable to add access to the Office.Interop.Excel namespace in the .NET Core Class library, but only for Windows
This cannot be done for .NET Core on OSX because the environment is
not suitable for interchanging COM objects.
This leaves only two options for manipulating objects in Excel for
Mac, both of which already exist: Embedded VBA or Javascript (Office
Add-ins).
Office Addins is a great new solution for web-driven data-oriented
objects in Excel - and its multiplatform nature is awesome - so is enjoying the main focus of
development from Microsoft. However it is not intended to be any
match for the performance of COM for managing complex spreadsheets,
since that's not its focus.
Which means there is no solution for managing objects within Excel
for Mac using C#, in the way that there is on Windows, and there
doesn't appear to be any prospect of one.
The bottom line: The very welcome .NET Core initiative looked like it was a fix, but sadly isn't, because of architecture limitations on OSX.
I have submitted this as an answer because I think I've come to the end of the line of enquiry on it, but if anyone thinks any of the above is incorrect, please shout!
Thanks.
This is the strangest programming issue I have seen in a long time.
I am using Microsoft Visual C# 2010 Express, C# and .NET 2.0 to develop an application. This application references a couple of dll/assemblies (those dlls are all generated on my machine).
Below is part of the code (it is all basic stuff):
public class PowerManagement
{
[TestCase]
public void PrepareTest(){
// Configure according to pre-conditions
Preconditions precondition = new Preconditions();
precondition.SetupPreconditions();
...
}
[TestCase]
public void PerformTest(){
TestcaseData testcaseData = new TestcaseData();
// Set Trigger and perform check
switch (testcaseData.triggerNumber){
case (1):
if ((new Trigger1(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
...
case (4):
if ((new Trigger4(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
default:
Report.TestStepFail("Not yet implemented");
break;
}
}
}
This application is then generated into a dll from Visual C# 2010 Express and used elsewhere and all is fine. The problem surfaces when I add another case to the switch-statement above (see below)
...
case (4):
if ((new Trigger4(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
case (5):
if ((new Trigger5(testcaseData)).Validate() != 1)
Report.TestStepFail("failed");
break;
default:
Report.TestStepFail("Not yet implemented");
break;
I can still build without a single issue and generate the dll but when I use the generated dll I get the following error:
A .NET exception (InvalidProgramException) occured in the module PowerManagement
Error message: Common Language Runtime detected an invalid program.
Throwing method: PowerManagement.PerformTest
(the issue happens even if I copy case(4) and paste it as a new case, so it has nothing to do with Trigger5-class)
What is happening here? I have looked through the other InvalidProgramException and Common Language Runtime in Stackoverflow but none seemed related.
I know this issue is strange so please let me know and I will provide more information. I am using a 64-bit Windows 8 machine, if that matters. I have already checked for any updates on VS and .NET updates. I havet also regenerated all the dlls a couple of time ans also created the solution from scratch a couple of times.
Just wanted to add my experience for this...
In my case, I am hosting my C# Web API on Azure and I encountered this message when trying to log in to my API.
I had to go into my Azure management portal (portal.azure.com), go to App Services, choose my Web API program and click Restart from the Overview screen.
After this, the program worked as normal again.
Did not find any further clues in my logs.
I finally managed to solve this issue.
I unchecked code optimization in C# Express and that solved the issues. Still the weirdest thing, but since we are using old tools and framework we can not really blame anyone.
Try enabling 32-bit applications in your application pool advanced settings.
I had this problem after upgrading to Visual Studio 2017 v15.8.6. The problem went away when I removed the assemblyPostProcessorType attribute in the compilation tag in web.config.
According to MSDN: "Generally this indicates a bug in the compiler that generated the program."
I would start by making sure you have all the updates installed on Windows, .NET and Visual Studio.
You should also check out Q312544 on Microsoft Support.
I've occasionally encountered this error after a deployment to an Azure WebApp using MSDeploy. The error has always disappeared after redeploying for a second time.
Our build and deployment are two different steps, the the redeployment is sending over the exact same files each time - this suggests the problem is not uniquely a compiler issue as suggested elsewhere in this question's responses.
Could be a bug in MSDeploy, or in the version of IIS used for WebApps in Azure perhaps...
Such problem could be caused by bugs in tools manipulating the IL of assembly after compilation, for example if you are using Fody and its plugins. At least there is a bug in Fody MethodDecorator which causes such effect, see
https://github.com/Fody/MethodDecorator/issues/8
If you are having this issue specific to Azure Web Apps - check for installed extension Microsoft.ApplicationInsights.AzureWebSites - or it's friendly name Application Insights extension for Azure App Service and remove it via kudu.
We found this extension was potentially interfering with msdeploy pushes - there was a process snapshotholder_x64.exe running under the IIS w3wp.exe process. Someone likely enabled this extension via the azure portal.
If your issue pertains to a web api dotnetcore deployed to an azure app then this could be caused by application insights. Setting the application insights at the blade level should fix the problem. Also note that there seems to be an unresolved issue with setting it at the blade level as recommended settings vs basic. Basic being the value that works.
Running into this issue deploying a Web Api as an API App on Azure. An initial request to any endpoint would result in the expected response; however, subsequent requests would return the same Common Language Runtime error. I figured out the problem started when I enabled Recommended collection level on the Application Insights blade on my web app. I set recommended and enabled all radio buttons. Reverting this change stopped the error. For reference, the API I am running is running Microsoft.ApplicationInsights 2.8.1
For reference:
https://github.com/dotnet/coreclr/issues/18323
I was doing some powershell automation in a console application using .net core 3.0 when i started receiving this error. I guess .net core is not compatible with System.Management.Automation so i changed it to .net framework 4.7, everything worked well after that
I resolved this issue by doing the following:
Rename C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Performance Tools\vsinstr.exe to C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Performance Tools\vsinstr.exe.broken
Rename C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Performance Tools\vsinstr.legacy.exe to C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Performance Tools\vsinstr.exe
Rebuild the solution
-uncheck "code optimization" (referenced dlls included)
-Upgrade to .net framework 4.6
Out of nowhere we started getting XXX webservice Exception , System.InvalidProgramException: Common Language Runtime detected an invalid program.
Copied compiled website to a different environment - works just fine.
Copied to a different server - works just fine.
I noticed that this exception started when server was reset (either rebooted or app pool reset). When researching this issue, I noticed comment by Brian Reichle on Jun 6 '16 at 12:33
I would expect a bitness mismatch to result in a
BadImageFormatException rather than the InvalidProgramException
described in the question.
I was not familiar with InvalidProgramException exception but I was familiar with BadImageFormatException and the symptom is very similar to the one I get with BadImageFormatException issue. I can't say 100% why either exception happens, current running theory is its a 32-bit application running on a 64-bit machine, but we couldn't prove it nor could we perma-fix it. Enabling 32-bit applications on app pool did not fix the issue.
The only fix we know of, albeit temporary, is to simply recycle App Pool. No need to recompile or anything. Luckily, this happens not too often, maybe once a month or two.
I just ran into this problem myself. Even though VS created the virtual directory for me, it had vb as the default language, but I have a C# application. Changing this setting solved it.
This is an interesting exception that i came across while hosting on IIS. I solved it after finding out that my .NET Framework version on IIS was different from the .NET Framework version that my project was using. Please note if you happen to have other referenced projects/ddl(s) make sure you update their .NET Framework version too.
In my case it was Hasp protection (google: hasp sentinel protection key) SW which ruined the dlls.
To share my experience: had the same issue on x86 computer with my WindowsForms app, found out I've forgotten to copy .exe.config file with all dll redirections, after that everything worked like a charm.
In my case, the exception was caused by datadog tracer after upgrading from 3.1 to NET 6, by upgrading to their latest version, the issue was fixed.
Here is the diff in my dockerfile.
-RUN curl -LO https://github.com/DataDog/dd-trace-dotnet/releases/download/v1.12.0/datadog-dotnet-apm_1.12.0_amd64.deb
-RUN dpkg -i ./datadog-dotnet-apm_1.12.0_amd64.deb
+RUN curl -LO https://github.com/DataDog/dd-trace-dotnet/releases/download/v2.14.0/datadog-dotnet-apm_2.14.0_amd64.deb
+RUN dpkg -i ./datadog-dotnet-apm_2.14.0_amd64.deb
https://github.com/DataDog/dd-trace-dotnet
Here is a link to a sample application which reproduces the error:
http://sdrv.ms/17j2Ale
I have three projects. One is a .NET 2.0 Windows Forms application (.NET App), one is a VB6 Standard EXE application (VB App), and the other is a VB6 ActiveX DLL (VB DLL). The .NET App references the VB DLL which is already registered. This VB DLL essentially launches Crystal Reports. The VB App launches the .NET App via the Shell() command. Here's what happens:
If I run the .NET App directly, I can open a Crystal Reports document with no problem. However, when the VB App launches the .NET App via the Shell() command, when the .NET App attempts to open the Crystal Reports document, I get an Out of Memory error.
Now here's the kicker - this worked on Windows XP, but when we attempt to launch it in Windows 7 64-bit, we run into this issue. I'm sure there's got to be a simple solution out there for it. Any takers?
You can jump to Update 5 where I narrowed down the problem.
Update: I also tried creating a second .NET 2.0 Windows Forms application (.NET Launcher), and launched the .NET App from it via:
Process.Start(#"C:\Path\OtherApp.exe");
and when I tried open the Crystal Reports document in the .NET App it still gave me the same Out of Memory error.
Update 2: removed due to update 4
Update 3: So today I discovered that the reason the .NET App was able to open the report when it was launched directly was because I was launching it within Visual Studio. When I tried the executable outside Visual Studio, the error returns. I noticed that Visual Studio, as of 2005, began using a vshost.exe to launch windows applications to speed up debugging startup: http://blogs.msdn.com/b/dtemp/archive/2004/08/17/215764.aspx
When I disabled the vshost feature, the out of memory error returned. So I suppose the question is, what is this vshost process doing that allows it to work on windows 7?
Update 4: I was able to compile the VB6 DLL with debug information and load the source and debug information into Visual Studio and step through it when the .NET app executes the VB6 code. The Out of Memory exception comes from this line:
Dim myForm As frmTheForm
Set myForm = New frmTheForm 'OOM Error right here
So inside the vshost.exe this form is able to initialize but not without it.
Update 5: I have narrowed down the problem to the Crystal Reports ActiveX Viewer. I started a new VB ActiveX DLL project from scratch and started with only a form. This worked every which way. Then I added the Crystal ActiveX Report Viewer Library 11.5 - and the error returned! It is definitely the Report Viewer. I'm told that this problem may be able to be fixed by a simple registry adjustment.
Update 6: I used Procmon.exe from Sysinternals and generated a logfile that can be found here:
http://sdrv.ms/194aO7A
I've got such problems when I use 32Bit C/C++-Dll's with .NET code running on 64Bit Windows.
If your .NET project has "any platform" as target then the runtime compiles the code to 64Bit on a 64Bit Windows, on a 32Bit Windows I think you'll have no problems.
You have to set your target platform to "x86", you wrote you did this. Please verify that all your .NET projects in your .NET solution are set to x86 as target.
The Crystal Reports *.dll should be a 32Bit COM *.dll, and the VB6 *.dll too.
I found a workaround solution to the out-of-memory error; however, it is not an allowable solution. Apparently, this issue is resolved in future versions of the crviewer.dll but Mister Uher makes it very clear in his response to my question here: http://scn.sap.com/thread/3405856 that we are not allowed to use the versions after 11.5 due to licensing restrictions. It would seem this is a common question he receives. Unfortunately, we are forced to accept the response that we are to upgrade our applications to .NET. If anyone else is feeling adventurous enough to attempt to troubleshoot the out-of-memory exception, I would am happy to leave my sample project above available to anyone who wishes to venture it. Best of luck to anyone else feeling my pain of CR 11.5 interop support.
Not sure if this information will help, but I have faced similar problems in the past with crystal and a Web Forms applications. I resolved it by ensuring that the application pool has the 'Enable 32 bit applications' option checked? You can find it under the advanced settings -> General....