I am using Entity Framework in an application i am working on, however when i try to launch it from another user's machine, while trying to load the EDM i get an Exception stating that the request for the AspNetHostingPermission has failed. The assemblies are located on a network share.
The assemblies are not signed and as far as i know, since 3.5 SP1, assemblies on network shares run under full trust. What is going wrong?
EDIT: It seems this is a general trust issue, considering that i also got an error about ReflectionPermission.
This is definitely a trust issue. Other people have reported the same error when running from a network share.
Related
The problem
We have a native application, that integrates with Outlook through COM/interop.
Intermittently we experience different errors relating to COM, MAPI, Redemption and the Windows Registry. And this is only at a single client installation.
It works 95-99% of the time. This percentage is extrapolated from looking at our log files.
We have quite a few other client installations, that never get the errors with the same version (same code) of the native application. We only experience the errors at this one client installation.
That leads me to believe the problem is likely to stem from something different at the client installation and not the code. But this is of course only a hypothesis.
Errors
Error one
Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)
When calling:
var outlookApp = (Application) Marshal.GetActiveObject("Outlook.Application");
var mapiObject = outlookApp.GetNamespace("MAPI").MAPIOBJECT; // <-- This line causes the error
at Microsoft.Office.Interop.Outlook.ApplicationClass.GetNamespace(String Type)
Error two
Interface not registered (Exception from HRESULT: 0x80040155)
When calling:
Microsoft.Office.Interop.Outlook._MailItem.get_Attachments()
Error three
Error in MAPILogonEx: MAPI_E_LOGON_FAILED
When calling:
Redemption.IRDOSession.Logon(Object ProfileName, Object Password, Object ShowDialog, Object NewSession, Object ParentWindowHandle, Object NoMail)
Tried so far
Reinstalling the entire machine from scratch
Reinstalling Office
Repairing Office
Checked the registry to see if multiple version of Office are present
There is only one version - "9.6" (Microsoft Office Standard 2019)
Run regsvr32 on the Redemption dll
Info:
Skype/Skype for business is not installed
Exchange Online is used, not om premise
Windows, Outlook and our native application are all x64
The strange thing is that is works most of the time. If it was a problem with the registration (registry), i would expect it to fail every time.
It looks like it might be a MAPI problem, but again it works most of the time.
I have been researching the problem for a few days now and haven't been able to find out why the problems are occurring intermittently. I have found a lot of information on the different errors, but they all seem to occur consistently; the errors occur every time the code is called in the error scenarios i have found.
Has anyone experienced anything similar or know why it might be happening?
Your machine is corrupted or any malware is presented. The problem is not related to the Redemption library because even the Outlook object model gives errors related to windows registry keys required for the COM interoperability.
TYPE_E_LIBNOTREGISTERED and REGDB_E_IIDNOTREG errors are a pretty strong indication that some COM registry keys are missing. Try to completely uninstall and then reinstall Outlook (not just Repair).
I'm building a website in VS2015 (C# using Razor)
I see many posts where people say that they receive this error on their server, but not localhost - my issue is the opposite. I'm seeing this error in every *.ashx file preamble in this specific Website only while running Localhost on my development machine:
ASP.Net runtime error: Loading this assembly would produce a different grant set from other instances (Exception from: HRESULT 0x80131401)
This error prevents me from using Intellisense in the file - and I really need it for this next handler.
What I've Determined: - The issue is specific to this Website. I have other websites that do not produce this error, so there isn't a need to modify registry or change PC configurations.
What I've tried:
IISReset (Restart PC) [*before I realized problem was local]
Changing Registry by adding LoadingOptimizer DWORD [*before I realized problem was local]
Compared XML of a working Web.config file. (Other than assembly differences I played around with other differences and still nothing)
Any suggestions?
Logged into a customer environment today to check logs and just generally do an inspection, only to notice some tasks had failed in one application.
Application is written in c# .net v4 running inside of IIS and exports to Sharepoint 2007.
I can't be 100% sure if .net or SharePoint is the culprit. These are the errors I got:
Task Failed: Server was unable to
process request. ---> Could not find
file 'C:\Windows\TEMP\qbckfur1.dll'.
Export 26.05.2011 15:00:21 Failure
Task Failed: Server was unable to
process request. ---> Could not find
file 'C:\Windows\TEMP\2shjg2xb.dll'.
Export 26.05.2011 15:30:13 Failure
Task Failed: Server was unable to
process request. ---> Could not find
file 'C:\Windows\TEMP\b7utp199.dll'.
Export 26.05.2011 16:00:15 Failure
Task Failed: Server was unable to
process request. ---> Could not find
file 'C:\Windows\TEMP\ozr2umkm.dll'.
Does this look familiar to anyone?
This is a problem with XmlSerialization (beleive it or not). I ran into this with a custom ASP.NET MVC app. Apparently, when you call Serialize or Deserialize on types marked as "Serializable", .NET will generate an assembly on-the-fly to support the serialization and it attempts to write that assembly into 'c:\windows\temp'.
Even if Everyone has full control access to that directory I have still seen this occur when running an app from within an IIS App Pool. Especially in applications that has a lot of serialization activity.
If this sounds like your problem, the solution is to "pre-compile" the Serialization assembly and include it in your application with sgen, part of the Windows SDK.
This post highlights a similar issue: Serialization issue on MSDN Social
Here is the MSDN article on the tool: sgen reference
Final Note: There is a separate version of the Tool for .NET 4.0 so make sure you are using the correct version when generating your assembly.
I am using a quickbooks sdk that containst the QBFC8Lib dll
everything works fine on my dev machine.
when I publish to my live server I get the following error:
System.BadImageFormatException: Could not load file or assembly 'Interop.QBFC8Lib' or one of its
enter code heredependencies. An attempt was made to load a program with an incorrect format
I have the sdk installed on both my dev machine and the live machine. still getting this error
You areexactly right. on the server I went to the application pool for this application and needed to set enable 32 bit applications to true. That did it. Thanks for your help
I am trying to change the Terminal Services settings programmaticly. I learned that you must use tsuserex.dll. Being c# i ran tsuserex through tlbimp and created TSUSEREXLib.dll then registered it with regasm. I got it working and wrote a framework program with it as a prof of concept. However today after I made some changes when I run my program I get the error
Unable to cast COM object of type 'System.__ComObject' to interface type 'TSUSEREXLib.IADsTSUserEx'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{C4930E79-2989-4462-8A60-2FCF2F2955EF}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
it thows the exception on the line
IADsTSUserEx iad = (IADsTSUserEx)((DirectoryEntry)user.GetUnderlyingObject()).NativeObject;
This exact line worked fine in the test project. I know user is a valid UserPrincipal, Googleing I found this is usually just needs the dll re-registered, but even after unloading and reloading it it still will not work. What am I missing to cause my dll to stop working.
I know this is an old thread but since I had trouble recently finding all the required steps to get the Terminal Services components working on Windows 7, I wanted to share what I found. I think the steps below are more reliable than copying the tsuserex.dll from a server and trying to register it.
From what I understand, on any operating system you need Remote Server Administration Tools (RSAT) installed in order to modify Terminal Services attributes of a user account programmatically. On some versions of Windows this requires a download. But on Windows 7, RSAT is already installed.
But you may need to enable it using the configuration options in Control Panel (appwiz.cpl). Under "Turn Windows features on or off" goto "Remote Server Administration Tools" then ensure that "Remote Desktop Services Tools" is checked.
After I did this (and rebooted) I was able to use the components from tsuserex.dll via PowerShell (e.g., Set-QADUser -Identity testUser -TsHomeDirectory "c:\tshome"), and by adding a reference in Visual Studio 2010 (to "tsexusrm 1.0 Type Library").
You almost certainly need to re-register your TLB on the target machine. What likely happened is you have your assembly, interface or type GUID not hard coded in the application and hence it's changed on every rebuild. So after rebuilding and deploying your type no longer matches up with the previously registered TLB.
The correct answer is that I am a idiot for not reliseing that my build environment did change. I moved to a new workstaion that was windows 7 corprate instead of server 2003 when i started on the project. Win7 corp does not have tsuserex.dll in its system.
Visual Studio Build Setting „Platform target“ disable=> “Prefer 32-bit” solve the Problem.