I created a dll file built (Project:win32 app, ATL and COM object using Visual studio 2008) in 32 bit. In win 7 32 bit OS, After registering my dll i'm getting "ABC" option in context menu(on right click). Now i move to win 7 64 bit OS. Dll loaded successfully, but i'm not getting "ABC" option on right click(in context menu). Can anyone please point me where i went wrong or any suggestions ?
Note: Right click on Folder gives "ABC" option.
A shell extension compiled for 32bit will run only in a 32bit process. The Windows Explorer of a 64bit Windows is a 64bit process, so it requires a 64bit shell extension.
If a 32bit application would use the fileopen dialog (on a 64bit Windows), the dialog would require a 32bit shell extension. So it's recommended that you install your extension like that:
Win32: 32bit Shell Extension
Win64: 64bit and 32bit Shell Extension
To do this, you have to give different GUIDS to the 32bit / 64bit shell extension. Hope that makes it a bit more clear.
Edit: As Raymond suggested, it seems that you can use the same GUID for both extensions.
Related
Im developing continually an inventor Addin in VB.Net in visual studio 2019 ,
i have multiple machine different builds , but once in a while some machine just don't want to load the Addin f.e. the current version i have now works on all machines except one AMD machine .
When i compile the same project with the same settings no changes at all on the AMD machine with ANY CPU build option it runs without problem . When i do it on my primary developing machine it does not work on this other computer.
I checked dependencies with dependency walker , i do not get any error messages .
When i make breakpoints in DEBUG mode and debug dll compilation in the first methods called in the "StandardAddInServer.vb" file it does not reach it on the AMD machine when it is compiled on the Intel machine. But in reverse it runs smoothly .
I have no idea what this could be and I'm only speculating that is has to do with AMD/Intel difference of the machines . Any help would be appreciated to come to a solution.
Inventor 2018.3.7 Professional Build 287 is on the Intel i7-4771 machine Visual Studio Community 2019 16.3.9 , .NET 4.8.03761
Inventor 2018 Professional build 112 is on the AMD Ryzen 7 3700X machine Visual Studio Community 2019 16.7.2 .NET 4.8.03752
Any more information which could be helpful will be provided gladly .
Well.... i tought lets make the maschines identical in regards to software .. i started installing inventor updates one by one at Version 2018.3.1 the Addin magically was working .... so i hope i help somebody if the , addin automatically unloads without any error , its probably autodesk inventors fault ...
Are you using ANY CPU ,or are you forcing the project to a given bit size?
If you don't set this, and leave it at ANY CPU? Well, if you launch the application from Visual Studio (such as installing on that target machine), then the application will run as x32 bits.
HOWEVER if you launch the program from the windows command line (command prompt).
Well, if you use the x64 bit command prompt, you get a x64 bit running - in-process program. If any of your external .dll's or libraryes are x32 (or not compiled with ANY cpu), or you using any un-manage code libraies (say like ghostscript or some such)? Then your program will run (or try to) as x64 bits.
However, if you launch a x32 bit windows command prompt (there are two of them - one is x32, and one is x64). So, if you launch the .net exe (your program) from a windows x32 bit prompt, then your program will run in-process as x32 bits.
So, be careful here. Using ANY CPU from Visual Studio will ALWAYS get you a x32 bit program - including debugging. But RUNNING the program (launching outside of VS) will not always be x32 bits.
And the above behaviours seems to explain your issues/problems on the AMD machine. It was NOT that you installed VS on that machine, but that using VS to launch your program in fact FORCED it to run as x32 bits.
Bottom line:
do NOT use ANY CPU unless that is exactly what you need, and that you are VERY sure any external libraries are also compiled as ANY CPU, or in fact that any external libraries doe NOT USE any un-managed code.
All in all? I would config your project to force run as x86 ALWAYS, and thus you not get some surprises of code not working.
I doubt very much that the AMD CPU is the issue, and installing VS only worked because of forcing your project to run as x32 as opposed to x64 bits. It has zero to do with AMD here.
You could try with a former framework version like 4.6.2. That should fix the problem. It could be that the newer service packs of Inventor can deal with addins created with newer .net versions. When 2018 Inventor was released, .net 4.8 was not available.
Was Albert wrote is true as well. If the architecture of your dll doesn't meet that of your host process, it can't be loaded. A 64bit process can use 64bit dlls only whereas a 32bit one can deal with 32bit dll only. A .Net project won't be compiled by Studio into fully functional machine code (nowadays you can do this as well), but intermediate code only, which will be compiled finally by the .net framework on the target machine. If anyCPU is selected, you don't have to provide different versions for different hardware because of this behaviour.
Thank you for any and all help... I've never seen this bug before... I have several vendor supplied DLLs for talking to a Signature Capture Device. We build our C# windows app platform target set to "any cpu" on an XP x86 machine. When the application is run on Win7 32-bit computer it works fine. When it is run on Win7 64bit computer it fails.
Running the Visual Studio 2010 debugger on Win 7 x64 in "Debug mode" works fine. Running in Release mode on Win7 x64 fails.
I can change the platform to target x64 then Release mode gives "interops made for a different target platorm." When I delete and recreate the interops for 64 bit target I get "ActiveX not properly registered".
Thank you in advance.
Make sure you module not depends of 32 bits libs.
Use Dependency Walker or Fuslogvw.exe to diagnose module load fail.
To interop 32/64 bits COM see Access x86 COM from x64 .NET
My solution was to change the Project->Properties->Build->Platform Target from "any cpu" to "x86". The application now runs on win7 64 bit and 32 bit and XP x86.
I'm using this code in XP 32-bit OS to get the %windir%\windows\system32 folder path.
sysFolderPath = Environment.GetFolderPath(Environment.SpecialFolder.System)
What I want to know is that will this same code return the %windir%\windows\syswow64 folder when used in Windows 7 (64/32-bit)?
It will return c:\windows\system32, even in a 32-bit program that runs on the 64-bit version of Windows. Do not fix this, it doesn't need fixing. Because when you use that path, Windows will automatically remap it to c:\windows\syswow64. The file system redirector takes care of it.
I tried on my Windows7 box with .NET 4.0
This code:
Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.System));
Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.SystemX86));
Prints the following from both 32- and 64-bit process:
C:\Windows\system32
C:\Windows\SysWOW64
Nope. On my Windows 7 64-bit box, targeting x64:
C:\Windows\system32
Is there a way to compile a VB6 component into 64 bits?
My feeling is that the answer is "no", but I would like to confirm this.
Please, if you can, paste a link to an authorative source that would confirm.
No. I hope this counts as authoritative.
64-Bit Windows
Visual Basic 6.0
runtime files are 32-bit. These files
ship in 64-bit Windows Operating
Systems referenced in the table below.
32-bit VB6 applications and components
are supported in the WOW emulation
environment only. 32-bit components
must also be hosted in 32-bit
application processes.
The Visual Basic 6.0 IDE has never
been offered in a native 64-bit
version, nor has the 32-bit IDE been
supported on 64-bit Windows. VB6
development on 64-bit Windows is not
and will not be supported.
No it cannot (well Microsoft has not released a compiler to compile it for a 64-bit environment), but this does not mean that it won't run on a 64-bit system. To run it in conjunction with IIS, you'll need to install the 32-bit version of IIS.
I'm developing SharePoint solutions on a virtual 32bit machine, and I use Wix to package the setup.
I'm targeting both 32bit and 64bit environments with my solutions, but in order to create 64bit MSI's, I need to have have a 64bit machine and the 64bit version of WiX.
Normally, this wouldn't be an issue, since I would have just simply use a 64bit dev environment.
But there are some issues with developing SharePoint solutions on a 64bit platform, which more or less forces me to develop on the 32bit platform.
Because of that, I can't create a 64bit MSI's, unless I copy the source files to a 64bit machine just to build the 64bit MSI, which feels a little bit cumbersome.
Is there any trick to flag/build the 64bit MSI package on my 32bit dev box, if it's even possible?
You do not need to run a 64-bit development machine to create a 64-bit MSI file.
What makes an MSI file "64-bit" is simply that the "Template Summary" field in the Summary Information Stream is set to "AMD64;1033" (one possible example) instead of "Intel;1033".
This MSDN article might provide you more information.
AFAIK the Wix tools set is agnostic to platform, you need to install the x64 version, and you need to use the proper flags inside the setup (there are various of places you need to be explicit about x64, more info here).