I am trying to register a dll using regsvr32 in a cmd window. I do this on an administrator account, but I need this dll to be registered for all the users. Turns out regsvr32 does not do that, it only registers for your current user. Well, when you use it this way anyways: "regsvr32 /i "C:\MyDll.dll"" What happens; The entry is added to Local_User, and Classes in the registry, but not Local_Machine.
The msdn article on regsvr32 says it also takes a [cmdline] when using the /i option. But the article fails to specify what I can put in place of [cmdline]. Google is refusing to help me as well, so I'm a bit stuck on this.
I realize this is not exactly on the topic of programming, but this is something programmers might know, so... Has anyone run into this before? Perhaps someone knows how this [cmdline] tag works? Are there any other ways to add this dll to all users? (Apart from editing the registry manually that is.) Any insight would be greatly appreciated!
What you put in place to [cmdline] is determined by the DLL you're registering. regsvr32 will just pass that text to a function called DllInstall in the DLL. If you want to know what to pass, you must consult the documentation for this particular DLL.
Related
During web application creating i got below popup message:
"Visual studio does not have permissions to read the template information from the registry. this is often caused by registry permission problem."
Any one have any solution?
Please help me. i wana to see Visual Studio new features.
Thanks
this might be quite late as an answer, but I excpierienced the same problem and I found the solution on a msdn page : here is the original solution message :
I came across this issue with Visual Studio 2010 and Windows 7. I did not find this problems source as of yet but, I have found many Visual Studio users encountering it. I tried Michael's solution to this problem and it did more damage then anything else. It even went as far as to make Visual studio to boot into "Shell mode" and tell me the registration was not valid.
Using System Restore I rolled back the changes made by the subinacl tool and Michaels script (it probably was not meant for Windows 7, causing the errors in the first place) .
being a long time visual studio user and a pretty good trouble shooter, I knew the subinacl was the proper tool to correct the problem, but the script was incorrect for my perticular setup. I adjusted the script as follows: (this is a batch script)
cd /d "%programfiles% (x86)\Windows Resource Kits\Tools"
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /setowner=domain\user
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /grant=everyone=f
/grant=administrators=f /grant=system=f
pause
I tried to include the "setowner" command with the grant commands (on the same line) but it would throw errors all the time.
This script fixed MY "Requested registry access is not allowed" with Windows 7 and Visual Studio 2010.
if you want to try this script: Follow Michael's instructions, but use the script provided in this post and replace the "domain\user" with the proper credentials. You may also need to change the Path of Windows Resource Kits if you installed it in a diffrnet place or are not using a 64 bit OS. Before using this script please backup your registry.
I hope that that helped!
*the original web page was : http://social.msdn.microsoft.com/Forums/en-US/c273b0e1-7f46-4065-afaf-4edf285d2531/vista-wpfapplication-requested-registry-access-is-not-allowed
I had this problem too. Followed the post by user2698666 without success. Stuck Process Monitor on it and found there were more registry entries causing a problem called WDExpress. Thought I'd post my fix incase anyone else has same problem:
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /setowner=domain\user
subinacl /subkeyreg HKEY_CLASSES_ROOT\VisualStudio* /grant=everyone=f /grant=administrators=f /grant=system=f
subinacl /subkeyreg HKEY_CLASSES_ROOT\WDExpress* /setowner=domain\user
subinacl /subkeyreg HKEY_CLASSES_ROOT\WDExpress* /grant=everyone=f /grant=administrators=f /grant=system=f
I had the problem with Visual Studio 13, where i wanted to add a webtest project for my newly created solution.
Tried the above trics to set ACL but it didn't work.
Finally used the Procmon.exe to locate what visual studio was doing (Include only process name devenv.exe) and look for result Access Denied. It will tell you what registry key is not accessible.
In my case it was the regkey HKCR.webtest (HKEY_CLASSES_ROOT.webtest) that caused the problem. Taking ownership and assigning acces to this solved my problem.
I do not know how the root cause of the problem.
The above didnt work for me as I kept being denied in regedit even though i was admin.
I found this on another site:
psexec -i -d -s c:\windows\regedit.exe
psexec is available from Microsoft here
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
This gave me full registry access. I tried to give admin owner to specific keys like above but VS 2012 express was still throwing that registry permission error. So I finally just added Administrator to the permission list of the entire HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ directory in regedit. Then gave admins full control.
This worked. I can now create a project without that infernal error!
This issue has nothing to do with permissions in the context discussed. The issue is caused by an incorrect path to the template files in the registry due to sloppy installation program testing by Microsoft. The incorrect path throws an error when a user tries to start a new project and, true to Microsoft style, displays a generic and meaningless error message about permissions.
Here's the issue specifically. In some machines (assuming C: is the primary drive and user1 is the user's login name and version 2013) the location of the template files is C:\users\user1\my documents\visual studio 2013\projects. Unfortunately, the installation path written by the installer in the registry is C:\users\user1\documents\visual studio 2013\projects. So, it's pointing to \documents while the correct location is \my documents. To be sure, look where your visual studio 2013\projects folder is located - either documents or my documents - and change the registry key to the correct location.
For my example the key is at HKEY_CURRENT_USER\software\Microsoft\VisualStudio\12.0\NewProjectDialog\MRUSettingsLocalProjectLocationEntries the path is located in the Value0 entry. Check it and change to make it point to exactly where your project folder is.
Lars Meldgard's use of ProcMon was a good tip and helped me. I just wanted to include a picture of what an access denied looks like in ProcMon. I had to do it one registry key at a time--this wasn't the only one. It was very cumbersome and slow, but I was able to knock them off one by one and give full rights on each one. (That part is a hassle too, because I had to take ownership, then close regedit, then go back in so I could set the permissions; you can't do it all in one fell swoop.)
Does anyone know if I NEED To wrap my Office 2007, vsto-based add-in in a MSI? It seems to be a lot of extra overhead and headache, just to have it not work anyway.
When I do get it to install, I still need to run the vsto installer, even though I have tried to use the |vstolocal switch to keep the add-in's deployment centralized.
Has anyone pulled this kind of install off successfully?
I've deployed VSTO from SCCM without using an MSI.
The trick is a simple command line:
"%commonprogramfiles%/microsoft shared/VSTO/10.0/VSTOInstaller.exe" /i <path to vsto>
VSTOInstaller.exe [[/install ] | [/uninstall ]] [/silent]
[/help]
/install, /i: Install the solution. This option must be followed by
the fully qualified path of a deployment manifest in the form http://,
https://, or \servername\foldername.
/uninstall, /u: Uninstall the solution. This option must be followed
by the fully qualified path of a deployment manifest in the form
http://, https://, or \servername\foldername.
/silent, /s: Install or uninstall without prompting for input or
providing information.
/help, /?: Generate this help message.
EXAMPLE: VSTOInstaller.exe /i \servername\foldername\AddIn.vsto
Be aware that with the /silent option "trust for the addin has to be built into the project or it will default to 'don't install' when using the silent switch." (source: TechNet post)
I've tried it, and you don't need to wrap it in an MSI if you're happy for users to manually install it. If you:
use the publish tab in project -> properties
setup your "publishing folder location" and "installation folder URL" properly
set and all of the other meta-data properly, including stuff in your AssemblyInfo.cs file
whack the "publish now" button
share out the installation folder and email out the link
ensure that users have the right permissions to install it (local admin I guess, you'd need to check)
It worked for me. On Windows 7 and XP too.
The whole "this publisher is untrusted" thing is a complete mess, trying to fix that involves writing some really stupid code that tells Windows that "hey, by the way, I am actually trusted". I didn't bother and just told people to ignore the warning.
I'm guessing that you only need an MSI if you want to push out the add-in using active directory and do an automated install.
When I try to run Oleview I get an error saying that DllRegisterServer failed for IViewer.dll (sorry I wanted to post a screenshot but I can't until I get 10 reputation =p)
Oleview will run but like the msg says, you can't look at interfaces which is exactly what I want to do.
I found my iviewer.dll and ran regsvr32 on it just fine. So I'm not sure whats up.
Ack, should have done more due diligence. Found this on msdn which explains that you need to run Oleview as admin. Stupid UAC.
I tried it out and running as admin works for me.
You only need to run it the first time as admin. Make sure you open a tlb file though, so it registers IVIEWERS.DLL as COM server into the registry. After that you can run it as a normal user. This is explained in the Windows SDK readme, by the way.
During solution deployments & Feature activation, I am facing an on/off issue where the system is unable to find & load the FeatureReceiver class. Mostly it is file not found exception (even though the assembly is there in the GAC). I checked over the net and this seems it a common issue with solutions (wsp) packaging DLL to be GACed. (But, no one has any clue or solution!)
What is the recommendation and guideline to fix this issue? We are setting the flag to reset IIS in my solution definition - but that does not seem to help. The issue is more prevalent in multi-M farms.
Thanks
This is a general problem in SharePoint in cause of the "SharePoint 2010 Timer Service". Because this one caches the wsp's and during the deployment or feature activation old references will occurres this error!
So try the following link. I hope this solution will help you.
http://msscorner.de/en/2011/10/27/sharepoint-deployment-failed-to-create-receiver-object-from-assembly/
First try the solution linked to by Falco...
If that does not help, try this:
Open the event-receiver file created by sharepoint
Compare the GUID above the event-receiver-class with the one stated in the stack-trace "...class=7g3562-438dn4...
If it does not match:
Copy the content of the class
Delete the file
Create a new file by right-clicking the feature -> add new event reciever
Pass the content
First thing, you dont need to give iisreset as your wsp deployment would have already done that.
Can you check if the assembly name, version, public token specified in the feature.xml is same at the actual assembly that is deployed in gac? I am thinking there is mismatch in assembly signature
I'm using Visual C++. I'd like to really only have the DLL registered for the current user, even if the users is an administrator.
For that reason, I changed all of the project.rgs references to HKCR.
But, using Process Monitor while using regsvr32 to register the DLL, I notice that it still tries to create HKCR\TypeLib\{ ... }.
This happens on the call to CComModule::RegisterServer().
Is this inherent of CComModule? Is there anything I'm missing, in terms of configuration of Visual C++? I know that I can use RegOverridePredefKey, but I don't want to load more DLLs, and it's not a very elegant solution.
CComModule::RegisterServer() has a BOOL first parameter that indicates whether it should register the type library. Set it to FALSE and it will not try to.
HKCR is not mapped to the current user registry hive, if you really want to register the server for the local user use HKEY_CURRENT_USER\Software\Classes instead of HKCR.