strong-name signatures are not validated when an assembly is loaded into a full-trust domain (Mycomputer)
In the following documentation it is explained how to disable bypass of the signature verification for .Net Framework
Would someone know hot to deactivate bypassTrustedAppStrongNames in .Net Core ?
Thanks in advance
PS : We can see with the following code that on Linux or Windows the applications runs in FullTrust
Assembly.GetCallingAssembly().IsFullyTrusted
I have tryed the following configuration to disable the bypass running a .Net 6 app on windows (signed exe that loads an unsigned dll):
Create a DWORD entry with a value of 0 named AllowStrongNameBypass under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework keys
I expected that my application in .Net 6 would not load an unsigned assembly loaded from an signed executable assembly
Actual result is that the unsigned assembly is loaded for my .Net core App
modern .NET does not validate strong name signatures by design.
Related
My app uses LoadLibrary to load plugins at run-time and users can accidentally try to load 64 bit plugins in the 32 bit version of my application.
It looks like the error code returned from LoadLibrary is not very descriptive (says "%1 is not a valid Win32 application").
I am looking for ways to figure out if the plugin dll file is built 32 or 64 bit so that I can notify the user in a user friendly way.
Any ideas?
In order to retrieve information about an image such as the one you are looking for, just use the ImageHelp API
We currently have a 32bit application that requires various key/value pairs to be loaded from the registry before use.
Previously we had completed this by loading the .reg as part of the installation. Running it on 64-bit Windows the .reg components end up in the 64-bit store, but our 32-bit application looks in the 32-bit store.
I was thinking of using KEY_WOW64_64KEY to force our 32-bit application to always use the 64-bit store however this answer advises against that. Then I thought we could change the .reg file to point to the 32-bit store but the comment on this answer advises against assuming the key will always be called "Wow6432Node"
Is there any perferred way to do this (other than migrating the whole app to 64-bit)? What are risks of a 32-bit application using the 64-bit store?
As long as you don't pass the HKEY handle to non Reg* functions that expect x86==native registry I don't think there are any risks. (Filesystem redirection on the other hand is not per handle and can cause problems if a sub-function calls LoadLibrary or CoCreateInstance etc)
If using KEY_WOW64_64KEY seems like too much of a hack, why not have the (32 bit) installer write to the registry instead of using .reg files? The only downside by doing this is that if you create a x64 version of your app in the future it will not share the settings with the x86 version. (This might be a good thing or a bad thing)
I used RegCreateKeyEx from a win32 application(VisualStudio 2008) in 64 bit windows(Project built with target x64). It was able to create a registry entry. Now I have a dll file (Project built with target x64) which too wanna create registry entry but my dll is returning error code 5(Yeah! its a sign of access denied). My samDesired flag have KEY_ALL_Access + In linker->manifestfile->run as administrator chosen which still fails with error code 5. Whereas it works perfectly in 32bit windows(Project built with target x86). Am i missing something?
NOTE: I'm trying to create an entry at HKEY_LOCAL_MACHINE.
You can't create a registry key in HKEY_LOCAL_MACHINE because this isn't a hive. You need to put your key in HKEY_LOCAL_MACHINE\Software or (less probably) one of the other hives.
I don't know why this appeared to work when you were running 32-bit code in WOW64, perhaps this is a side-effect of the way the 32-bit view of the registry is presented.
getting a COM error trying to run 32 bit OOP COM exe's on a 64 bit OS.
Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
If I have a compiled 32bit EXE that reads registry for GUID's how do I resolve this?
David D
That's probably a registration problem. The type library is used when you use the standard marshaller for the out-of-process server. Which uses the info in the type library to figure out how to properly serialize the arguments of a function call. On a 64-bit machine, the type library needs to be registered in the HKLM/Software/Wow6432Node/Classes/Typelib key. It is referenced by the TypeLib key in the registry key for the interface, a subkey of HKLM/Software/Wow6432Node/Classes/Interface.
Use SysInternals' ProcMon utility to observe where it is looking, contact the server's vendor or author for installer support.
Found the answer... The .NET solutions I had were set to "Any CPU". Once I changed it to x86... this solved the issue.
Does anyone have any idea why CoCreateInstance would be failing on ITaskBarList3 on Windows 7 64-bit? The error code is 0x80040154, which is Class Not Registered.
The calling code (VB6) is:
Public Const IID_ITaskbarList3 = "{EA1AFB91-9E28-4B86-90E9-9E9F8A5EEFAF}"
Public Const CLSID_TaskbarList3 = "{EA1AFB91-9E28-4B86-90E9-9E9F8A5EEFAF}"
'....
Dim IID As GUID_API
Dim CLSID As GUID_API
Dim iTaskBarVB3 As ShellLib.ITaskbarList3
rc = CLSIDFromString(StrPtr(CLSID_TaskbarList3), CLSID)
rc = IIDFromString(StrPtr(IID_ITaskbarList3), IID)
rc = CoCreateInstance(CLSID, 0, CLSCTX_SERVER, IID, iTaskBarVB3)
The returns from CLSIDFromString and IIDFromString are both 0 (Success). I can find the string in the registry. Since my taskbar is obviously working just fine, I know the interface is able to be called by other processes just fine.
ITaskBarList3 is declared in a typelib compiled using mktyplib.exe. I've double checked the GUID values, and they match those in the SDK.
Any help would be greatly appreciated.
The most likely reason is that the calling code is 32-bit and the COM server is 64-bit and therefore can't be loaded as an in-proc server.
A possible solution could be to create a COM+ application for the COM server to force its creation as an out-proc server. However this will not help if the COM server is meant to supply an ActiveX control.
I'm also surprised to see the class id being equal to the interface id - it's common practice to have them different. Since you are not the developer of the component implementing that interface but only the consumer it's likely that you just misplaced the class id with the interface id and this is the reason why your client program is not working. You should find the class id of the class implementing the ITaskBarList3 interface and use it as the class id.
CLSID_TaskbarList3 doesn't exist! It's simply,
CLSID_TaskbarList = "{56FDF344-FD6D-11D0-958A-006097C9A090}"
which indeed has a different GUID than the IID_TaskbarList3 IID.
In COM you have typically one class implementing one or more interface. There doesn't generally exist a new class for every interface.
The ClassID wasn't the problem, as this worked correctly about a week ago. I was previously compiling on Windows Vista, 32-bit.
I've now updated my system to Windows 7, 64-bit. The problem isn't a matter of 32/64-bit compatibility. The TaskBar is accessible through Wow64, and I am able to call the interface just fine from a 32-bit ATL DLL.
I did some more searching, and I found a number of references on the web regarding problems with actxprxy.dll on 64-bit windows. This is the DLL where the interfaces appear to reside, according to OLE Viewer.
Anyways, some people have had luck with various combinations of .reg scripts and unregistering/re-registering the files. Unfortunately, I'm not one of those people.
I've decided to save myself the headache, and just wrote a small DLL using ATL, and I have the VB code calling that. Works fine in that setup...
Thanks again for your help.