I am updating a native C++ DLL with COM components from Visual Studio 6.0 to Visual Studio 2019. The original project has a post build event to register the the DLL
regsvr32 /s /c my.dll
Looking at the help screen for regsvr32 the /c option is not listed and an online search and even Microsoft online documentation did not turn up anything on a /c option for regsvr32. I realize with VS2019 I can select the register output option under Linker Properties but I'd like to know what the reason was for the /c option in the original project.
The option /c does appear to be a valid since using it does not generate an error message whereas use of other invalid options does. The help screen above was generated with
regsvr32 /z my.dll
Prior to Windows 2000 regsvr32 /c used to send its output to the console (and VC++ 6 dates back to 1998, when NT 3.x/4.0 were still alive and well).
This was also mentioned in JSI Tip 6434 which corrects the "to the computer" typo in Q288373.
In Windows NT 4.0 and other previous operating systems, you could use the /C switch with Regsvr32.exe to send output to the console, which allowed you to script the process and test for the result. This functionality is no longer included in Windows NT 5.0 and higher.
After leaving my machine alone for a couple weeks, I returned to do some Qt-using-VC10 work. The first sign of trouble was a QtCreator error about "cl" not being recognized, which led me to discover that C:\Windows\System32 had somehow been removed from PATH. The inability to identify the "reg" command was making vcvarsall.bat fail to set VS100COMNTOOLS, as described here.
The aforementioned thread directed me to this, which suggested simply adding C:\Windows\System32 back to PATH.
However, my troubles were not over. Once C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvars32.bat (a script invoked by vcvarsall.bat) was able to invoke "reg", it failed to find the key necessary for setting VS100COMNTOOLS. The failure occured at the following line:
for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "10.0"') DO (
#if "%%i"=="10.0" (
#SET "VS100COMNTOOLS=%%k"
)
)
The output I got from vcvars32.bat (with unsuppressed output) was:
C:\Users\Bob\Desktop>for /F "tokens=1,2*" %i in ('reg query "HKLM\SOFTWARE\Micro
soft\VisualStudio\SxS\VS7" /v "10.0"') DO ()
ERROR: The system was unable to find the specified registry key or value.
Sure enough, the indicated location in my branch does not exist. The relevant subset of my registry tree looks like this:
HKEY_LOCAL_MACHINE\
SOFTWARE\
Microsoft\
VisualStudio\
10.0\
Debugger\
11.0\
...
9.0\
...
Debugger\
...
Does anyone know what is going on here? Could the automatic windows updates after my two weeks of absence be responsible? How do I fix my system so vcvarsall.bat can manage to set VS100COMNTOOLS?
I had essentially the same problem. In my case I was trying to install only the Visual Studio compilers and redistributables without any instances of the Visual Studio IDE. I took a long time looking into it, trying to resolve it 'correctly' without unnecessarily forcing environment variables or modifying or adding registry values.
Most advice starts with uninstalling any Visual Studio 2010 redistributes and/or compilers and then re-installing them in a particular order, usually after having installed the Windows SDK.
In my case this seemed to help but not completely resolve problems. I ended up doing the following. First in
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat
I commented out line 10 because if goto setup_buildsku is taken, the %VisualStudioVersion% variable never ends up getting set as it normally would later down in the file. (It doesn't matter that vcbuildtools.bat won't be called again, because I have that called first when I start my command prompt.)
Then, in
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\vcvars64.bat
in the labeled section GetVSCommonToolsDir, it goes looking in the registry at both HKLM and HKCU for
SOFTWARE\Microsoft\VisualStudio\SxS\VS7
and
SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VS7
The problem I had was (that because only the Build Tools are installed ?) there are no VS7 keys, only VC7 keys so the lookup fails.
Consequently I commented out lines 99-103 in vcvarsall.bat and my %VS140COMNTOOLSDIR% and %VS100COMNTOOLSDIR% variables are untouched. (They are already set in my environment before calling vcvarsall.bat).
Later, I see many "ERROR: Cannot determine the location of the VS installation." But my builds and compiles still proceed OK!
Yes, that's right. I had the same problem with the missing regKey SxS.
After re-installing my Visual Studio 10.0 - update SP1 - the SxS HKM-RegKey was re-defined in the HKM.
Recently I installed Build Tools for Visual Studio 2019 on Wine and found that vcvars64.bat doesn't work.
It is mainly due to the difference of cmd between Wine and Windows.
In addition, Wine(Windows) Registry doesn't have .NET Framework setup information.
What I added to Wine Registry is as below:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\SxS\VC7]
"FrameworkDir32"="C:\\WINDOWS\\Microsoft.NET\\Framework\\"
"FrameworkDir64"="C:\\WINDOWS\\Microsoft.NET\\Framework64"
"FrameworkVer32"="v4.0.30319"
"FrameworkVer64"="v4.0.30319"
I have Windows 7, 64-bit.
I'm trying to register a .dll (comdlg32.dll) using regsvr32. But I get an error that says the dll is read but the DLLRegistryServer entry point is not found.
I have run the command under both System32 and SysWOW64 and I have run my commands with "Run As Administrator".
My old MSComDlg.CommonDialog component is no longer working with 64-bit.
comdlg32.dll is not a COM DLL and cannot be registered.
One way to confirm this for yourself is to run this command:
dumpbin /exports comdlg32.dll
You'll see that comdlg32.dll doesn't contain a DllRegisterServer method. Hence RegSvr32.exe won't work.
That's your answer.
ComDlg32.dll is a a system component. (exists in both c:\windows\system32 and c:\windows\syswow64) Trying to replace it or override any registration with an older version could corrupt the rest of Windows.
I can help more, but I need to know what MSComDlg.CommonDialog is. What does it do and how is it supposed to work? And what version of ComDlg32.dll are you trying to register (and where did you get it)?
comdlg32.dll is not really a COM dll (you can't register it).
What you need is comdlg32.ocx which contains the MSComDlg.CommonDialog COM class (and indeed relies on comdlg32.dll to work). Once you get ahold on a comdlg32.ocx, then you will be able to do regsvr32 comdlg32.ocx.
Registering DLL for Fundsite
Outdated or missing comdlg32.ocx runtime library can be the problem of causing this error.
Make sure comdlg32.ocx file is not corrupted otherwise Download the File comdlg32.ocx (~60 Kb Zip).
Download the file and extract the comdlg32.ocx to your the Windows\System32 folder or Windows\SysWOW64. In my case i started with Windows\System32 but it didn’t work at my end, so I again saved in Windows\SysWOW64.
Type following command from Start, Run dialog:“c:\windows>System32\regsvr32 Comdlg32.ocx “ or “c:\windows>SysWOW64\regsvr32 Comdlg32.ocx ”
Now Comdlg.ocx File is register and next step is to register the DLL
Copy the Fundsite.Text.Encoding. dll into .Net Framework folder for 64bit on below path
C:\Windows\Microsoft.NET\Framework64\v2.0.50727
Then on command prompt and go to directory C:\Windows\Microsoft.NET\Framework64\v2.0.50727 and then run the following command as shown below.
This will register the dll successfully.
C:\Windows\Microsoft.net\framework64\v2.0.50727>regasm "Dll Name".dll
Have you unistalled your Internet Explorer?
I did, and I had the same issues, if so, you have to:
Reactivate IE (Control Panel -- Programs and Features -- Turn Windows features on or off).
restarting the computer
(important!) running Windows Update to get all available updates for Microsoft Explorer
restarting the computer (again)
Finally it works!
I have faced the same issue with COMDLG32.OCX and MSFLXGRD.OCX in Windows 10 and Visual Studio 2010. It's an MFC application.
Then I downloaded its zip file from the google after extracting copy them at following paths:
C:\Windows\System32 (*For 32-bit machine*)
C:\Windows\SysWOW64 (*For 64-bit machine*)
Then run Command Prompt as an Administrator then run the following commands:
For Windows 64-bit systems c:\windows\SysWOW64\ regsvr32 comdlg32.ocx
c:\windows\SysWOW64\regsvr32 msflxgrd.ocx (My machine is 64-bit configuration)
For Windows 32-bit systems c:\windows\System32\ regsvr32 comdlg32.ocx
c:\windows\System32\regsvr32 msflxgrd.ocx
On successfully updation of the above cmds it shows succeed message.
Information about missing entry point error installing legacy VB6 compiled applications on Windows 10 which I hope could be useful to someone.
Missing OCX files can be found in the "OS\System folder" of the Visual Basic 6.0 installer package.
Today I copied the relevant OCX file (from our network) to the local computer
And then I typed the commands below, as administrator, which normally work to register it.
cd \windows\syswow64
regsvr32.exe /u mscomctl.ocx
regsvr32.exe /i mscomctl.ocx
(add the path to the locally copied file for the /i command)
However today I got errors from both these regsvr32.exe commands.
The second error was giving the DllImport missing entry point error which is similar to the error mentioned by the original poster.
To resolve, one of the things I tried was leaving out the switch -
regsvr32.exe mscomctl.ocx
To my surprise it then said it was successful.
To confirm, the application started up properly afterwards.
SOLUTION OF Regsvr32: DllRegisterServer entry point was not found,
Go to systemdrive(generally c:)\system32 and search file "Regsvr32.exe"
Right click and click in properties and go to security tab and click in advanced button.
Click in owner tab and click edit and select administrators and click ok.
Click in permissions
Click in change permissions.
Choose administrators and click edit and put tick on full control and click ok.
Similarly, choose SYSTEM and edit and put tick on full control and click ok and click in other dialog box which are opened.
Now .dll files can be registered and error don't come, you should re-install any software whose dll files was not registered during installation.
I also had the similar problem while registering myinfo.dll file in windows 7. Following work for me:
Create a short cut on your desktop
C:\Windows\System32\regsvr32.exe c:\windows\system32\myinfo.dll
right click on the short cut just created and select as Run as administrator.
After windows update installed security update KB2687323, my VB6 project fails to load. Displayed error message is "'[project_vbp_path]/MSCOMCTL.OCX' could not be loaded--Continue Loading Project?". Note that the path in the messeage is the vbp file folder path instead of the control's registered path.
Details:
MSCOMCTL.OCX is registered in the usual system32 folder.
The executable produced by exactly the same project, an hour before the update runs fine and loads the updated MSCOMCTL.OCX (I have checked it with Process Explorer).
The security update description states that MSCOMCTL.OCX has a new fixed version. So I checked the project properties for "Upgrade ActiveX Controls" checkbox. I tried it both ways; checked and unchecked to no avail. VB6 IDE refused to load the upgraded OCX.
After hours of effort, system restore, register, unregister cycles and a night's sleep I have managed to pinpoint the problem. It turns out that the project file contains the below line:
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX
The version information "2.0" it seems was the reason of not loading. Changing it to "2.1" in notepad solved the problem:
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX
So in a similar "OCX could not be loaded" situation one possible way of resolution is to start a new project. Put the control on one of the forms and check the vbp file with notepad to see what version it is expecting.
OR A MUCH EASIER METHOD:
(I have added this section after Bob's valuable comment below)
You can open your VBP project file in Notepad and find the nasty line that is preventing VB6 to upgrade the project automatically to 2.1 and remove it:
NoControlUpgrade=1
The problem has been resolved by running the following in elevated command prompt:
command :
cd C:\Windows\System32\
regtlib msdatsrc.tlb
or
cd C:\Windows\SysWOW64\
regtlib msdatsrc.tlb
I hope this helps.
The problem:
Microsoft Office 2010 products (or later) install updates that break compatibility of MSCOMCTL.ocx and COMCTL32.ocx. Unfortunately this affects many other programs such Visual Basic 6 SP6 and even Oracle Virtual Box v5. The actual problem is HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0 registry key. You can find detailed background information about this problem here.
Here is another working solution:
The solution assumes you have not damaged your registry by deleting, replacing and re-registering MSCOMCTL.ocx and COMCTL32.ocx without unregistering the Office patch files.
Create a batch file called fix.cmd and place the following commands in it:
regsvr32 /s /u %windir%\SysWOW64\comctl32.ocx
regsvr32 /s /u %windir%\SysWOW64\mscomctl.ocx
del /y %windir%\SysWOW64\comctl32.ocx
del /y %windir%\SysWOW64\mscomctl.ocx
msiexec /passive /norestart /i KB2708437.msi
msiexec /passive /a KB2708437.msi
regtlib %windir%\SysWOW64\msdatsrc.tlb
Download from Security update for Visual Basic 6.0 Service Pack 6: August 14, 2012 the msi file and rename it to KB2708437.msi.
Note: A direct link to the Service Pack 6 download is located HERE.
Run fix.cmd and the problem will be fixed!
What fix.cmd does is to properly unregister and then delete the current MSCOMCTL.ocx and COMCTL32.ocx files, and then apply the latest Visual Basic 6 SP6 rollup patch. In fact, the script enforces the patch to be installed and then re-installed by updating every file, regardless of version. Finally it registers msdatsrc.tlb type library.
Please let me know if this works for you.
======================================================================
Advanced Solution:
If however you have accidentally damaged your registry, you need to get as many versions of MSCOMCTL.ocx and COMCTL32.ocx you can find. Then you need to start from the newer version going back to the older and register and unregister the ocx files.
The latest version of MSCOMCTL.ocx is 6.1.98.39 (v2.1) of May 2012 which is more likely the one installed on your system and causing all your problems.
The oldest (legacy) version is that shipped with Visual Basic 6 on 1998 6.1.97.82 (v2.0), or the one shipped with an early service pack 6.1.97.86 on April 2005.
Example:
regsvr32 /s comctl32.6.0.98.34.ocx
regsvr32 /s /u comctl32.6.0.98.34.ocx
regsvr32 /s comctl32.6.0.81.6.ocx
regsvr32 /s /u comctl32.6.0.81.6.ocx
regsvr32 /s comctl32.6.0.81.5.ocx
regsvr32 /s /u comctl32.6.0.81.5.ocx
regsvr32 /s mscomctl.6.1.98.39.(2.1).ocx
regsvr32 /s /u mscomctl.6.1.98.39.(2.1).ocx
regsvr32 /s mscomctl.6.1.98.34.ocx
regsvr32 /s /u mscomctl.6.1.98.34.ocx
regsvr32 /s mscomctl.6.1.97.86.ocx
regsvr32 /s /u mscomctl.6.1.97.86.ocx
regsvr32 /s mscomctl.6.1.97.82.(2.0).ocx
regsvr32 /s /u mscomctl.6.1.97.82.(2.0).ocx
regsvr32 /s /u %windir%\SysWOW64\comctl32.ocx
regsvr32 /s /u %windir%\SysWOW64\mscomctl.ocx
del /q %windir%\SysWOW64\comctl32.ocx
del /q %windir%\SysWOW64\mscomctl.ocx
msiexec /passive /norestart /i KB2708437.msi
msiexec /passive /a KB2708437.msi
regtlib %windir%\SysWOW64\msdatsrc.tlb
WARNING:
Do not search the internet for those files. To find different version of the OCX files download and extract official Microsoft Installer packages such as the following:
2005 Apr - Microsoft KB896559
2008 Dec - Microsoft KB926857
2009 Apr - Microsoft KB957924
2012 May - Microsoft KB2708437
It is also recommended to run CCleaner version 4.0 or later to fix any other ActiveX related problems on your computer.
To Fix the Problem:
Make a Batch file with the following code:
#echo off
reg query "HKEY_CLASSES_ROOT\typelib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.1"
if %errorlevel%==0 GOTO DELREGKEY
if %errorlevel%==1 GOTO REGISTEROCX
:DELREGKEY
reg delete hkcr\typelib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0 /f
:REGISTEROCX
if exist %systemroot%\SysWOW64\cscript.exe goto 64
%systemroot%\system32\regsvr32 /u mscomctl.ocx /s
%systemroot%\system32\regsvr32 mscomctl.ocx /s
exit
:64
%systemroot%\sysWOW64\regsvr32 /u mscomctl.ocx /s
%systemroot%\sysWOW64\regsvr32 mscomctl.ocx /s
exit
I use win7 and has same problem.
Today I solved this problem, through loading with many error with my project just give order to continue after that goto Project=> Component => Microsoft Windows Common Controls 6.0 (SP6) then save the project (file use was c:\windows\syswow64\mscomctl.ocx)
The solution for me is to install this VB6 patch. I'm on Server2008 (32-bit).
http://www.microsoft.com/en-us/download/details.aspx?id=10019
It makes me sad that we're still talking about this in 2014... but here it is. :)
From puetzk's comment: These are outdated: you want to be using Microsoft Visual Basic 6.0 Service Pack 6 Cumulative Update (kb957924).
I do not find NoControlUpgrade=1 on my vbp project.
Instead, I develop on both xp and windows7 x64. When I moved the project from window 7 to xp, the error occurred.
From what I find out, these are different:
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX
I just changed the #2,1 back to #2.0 on the vbp file and it can run immediately.
These kind of problems occurred before, so hope Microsoft explain and solve them accordingly.
Thanks.
On some computers, I've found that the "2.0" version of MSCOMCTL.OCX has been added to the ActiveX KillBits list, and thus the control won't be allowed to load or run--even in design view. Updating to the "2.1" version will resolve this, and is the recommended solution.
In critical cases, where you have to run a program "now", or you don't have access to source code, or the control is used 400 times in a large modular project, you can use a "big hammer" method and update the registry to re-enable the control:
**
WARNING: Editing the Windows Registry in the wrong way can mess up your computer big time. If you're not sure what you're doing, please leave it alone, or get some schooling before you proceed.
**
The clear the KillBit:
Run Registry Editor (regedit.exe or regedt32.exe)
In the left-hand panel, navigate to key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility{BDD1F04B-858B-11D1-B16A-00C0F0283628}
In the right-hand panel, double-click on “Compatibility Flags”, change the value from Hex 0x400 (Decimal 1024) to 0, then click OK.
Launch the application that uses the "2.0" version of MSCOMCTL.OCX; it should run as designed.
The ActiveX KillBits list is intended to give Microsoft the means to disable controls that are deemed to be a security risk, and they've designed the mechanism such that the ActiveX KillBits list will be re-applied to the system at seemingly random times, in addition to when an Update is installed, so you'll need to plan for re-applying the registry change. Making a registry merge file works pretty well, but it's not something you want to do everytime the app runs, because it's not a quiet process (there are ways to do this quietly using Windows Scripting, but you'll have to learn that on your own). The KillBit is checked only when the control is requested by an application, so you're safe from resets once the application launches and loads the control.
You may try to check your registry
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}
If it is 2.1 version, it will cause cannot load MSCOMCTL.OCX issue.
You may restore to 2.0 verion (not only copy the file, you should unregiser 2.1 and register the restored file)
Or
You may try latest 2.2 version
https://support.microsoft.com/en-us/kb/3096896 (file date: 5-Nov-2015)
https://www.microsoft.com/en-us/download/details.aspx?id=50722
Some version information :
6.0.88.62 (2.0)
6.1.97.82 (2.0)
6.1.98.34 (2.1) <<< not work for me
6.1.98.46 (2.2)
Same problem with VBA Macros using MSCOMCTL.OCX.
Problem still unresolved with solutions like "reg/unreg mscomctl.ocx"
Used the Info above of Rumi.
Edited my *.dot file, search for #2.0#0, change it to #2.1#0
--> it worked
I had this problem and tried many different solutions. They didn't work for me although I think this error occurs for a couple of different reasons. My solution is in my answer to this question here:
https://stackoverflow.com/a/15785253/2240058
Its worth a try if nothing else is working for you.
This problem mysteriously appeared for me today. I hadn't done any Windows updates, so I don't know the cause.
This fixed it (in elevated command prompt):
regtlibv12.exe msdatsrc.tlb
For me, this solution worked like a charm:
http://home.pacific.net.hk/~edx/bin/readmeocx.txt
Fix these two lines like that:
Object={F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0; COMDLG32.OCX
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX
Search the files (.vbp and .frm) for lines like this:
Begin ComctlLib.ImageList ILTree
Begin ComctlLib.StatusBar StatusBar1
Begin ComctlLib.Toolbar Toolbar1`
The lines may be like this:
Begin MSComctlLib.ImageList ILTree
Begin MSComctlLib.StatusBar StatusBar1
Begin MSComctlLib.Toolbar Toolbar1`
I recently put all my source on a windows 8 32 box. Had the issues loading mscomctl.ocx with existing projects.
I created a new project and add the common control (all). save the project and reloaded it no problem.
when you compare the project headers new vs old the old one uses reference=*\blah blah. I found removing this a replacing it with the Object={blah} sorted out the problem.
I continued to have problems after trying the things suggested here. In the end, it turned out that I had the wrong version of mscomctl.ocx in my SysWOW64 folder. I found the following versions kicking around:
Mar. 09, 2004 01:00 AM 1,081,616 mscomctl.ocx
Jun. 06, 2012 07:59 PM 1,070,152 mscomctl.ocx
Dec. 08, 2015 03:57 AM 1,070,232 MSCOMCTL.OCX
Getting the last one (1,070,232) solved this problem for me.
I had similar trouble, have a program running for last 10 years written in VB6, now client wanted to make some major modifications, and all my machines which are now windows 10; failed to open the project, it was always that nasty mscomctl.ocx error. I had done lot of things but could not solve the problem. Then I thought the easy way around, I downloaded the latest mscomctl (
Then opened a new project, added all the components like mscomctl, activx controls etc, saved it and opened this newly created project file in Notepad, then copied the exact details and replaced in the original project.... and bingo! The old project opened up normally without any fuss! I hope this experience will help someone.
In my case didn't work any solution above. Near to give up, removed any reference (using Arvo Bowen's fix.cmd file) and tried pasting mscomctl.ocx (version 6.1.97.86) in C:\Program Files (x86)\Microsoft Visual Studio\VB98 folder. It worked finally after more than 4 or 5 hours fighting for a solution.
I've recently upgraded to WIndows 7. When I try to sign the assembly in VS2010 I get an "Access is denied" error. I am logged as admin so I'm puzzled. What service account does VS uses that I should elevate its privilages?
Thanks,
Risho
I don't know if it's Window 7 or the company policy, but I had to take ownership of the C:\Users\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys folder and give myself full control. This corrected the issue.
Solution:
Run the following command from Administrator command prompt:
For 64-bit systems:
reg add HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\StrongName /v MachineKeyset /t REG_DWORD /d 0
For 32-bit systems:
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName /v MachineKeyset /t REG_DWORD /d 0
The change affects immediately.
Why this happens:
MS Assembly Linker ALINK (AL.EXE) used by Visual Studio to sign assemblies creates a temporary crypto key during its work. Actually it uses some internal CLR functions for this, and the problem is that CRYPT_MACHINE_KEYSET flag is used by default. This requires elevation, and that's why running VS "as Administrator" works.
But, fortunately, I found that CLR has a global flag for StrongName signing, and it's stored in the system registry under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName
and is controlled by DWORD value
MachineKeyset.
0 - use current user key set
1 - use machine key set (this is default)
Visual Studio is a 32-bit app and uses 32-bit version of AL.EXE for build. So on 64-bit systems it's subject to registry redirection, and the flag is located under the key
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\StrongName
It works on my VS2019, Win10, and .Net framework 4.8, but I didn't test it on previous versions though.
For windows 10 and VS 2015, I have to run VS as administrator.
On Win10 I gave the user who im starting Visual Studio with, rights to read, write, run, change and display for the folder:
C:\ProgramData\Microsoft\Crypto