I am trying to get a project to build on a machine but i get the following:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(744,5): warning MSB3075: The command "regsvr32 /s "C:\builds\working\\Win32\Debug\projx86.dll"" exited with code 5. Please verify that you have sufficient rights to run this command.
The previous error was converted to a warning because the task was called with ContinueOnError=true.
Build continuing because "ContinueOnError" on the task "Exec" is set to "true".
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(756,5): error MSB8011: Failed to register output. Please try enabling Per-user Redirection or register the component from a command prompt with elevated permissions.
The user account i am using is an Administrator on the machine so should that not have the highest privileges?
I can go to the startup and right click and run as administrator and that might sort it, but im trying to do an automated build and run of this project, so i cant use that method.
Anyone know how i might fix this?
Solution Explorer ->[YourProject]->Properties->Linker ->General->Per-user Redirection "TRUE"
I found this same issue when working on an C++ ATL project.
In my case, when I added a new ATL class I was missing a line in the resource file (.rc) that adds a resource type "registry" of the new class resource file (.rgs) . This creates the same permission issue stated above.
#LittleFairy answer is probably the best. But you could run Visual Studio as administrator.
Note: You need to explicitly start Visual Studio as administrator. Just the user account having admin rights isn't enough.
Related
I am creating a Azure build pipeline where I am using a powershell and MSBuild extension to create build. My project has multiple solutions and steps In msbuild. When I am running powershell from system I am able to create build successfully but when I am doing the same thing using Azure pipeline I am getting permission issues as below.
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(4169,5): error MSB3216: Cannot register assembly "C:\Agent\_work\1\s\2021-04-16 17-34-14\BHMessage\RssiStatisticsStorage\bin\Release\RssiStatisticsStorage.dll" - access denied. Please make sure you're running the application as administrator. Access to the registry key 'HKEY_CLASSES_ROOT\FixedNet.Common.TimeUtilities' is denied. [C:\Agent\_work\1\s\2021-04-16 17-34-14\BHMessage\RssiStatisticsStorage\RssiStatisticsStorage.csproj]
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(1620,5): error MSB8011: Failed to register output. Please try enabling Per-user Redirection or register the component from a command prompt with elevated permissions. [C:\Agent_work\1\s\2021-04-16 17-34-14\BHMessage\FNSKMSCache\FNSKMSCache.vcxproj]
Also i am using VS 2013 and i am able to build solution manually in visual studio. Please don't suggest go to project properties and do this. I have given all access to registry and visual studio is also logged in with admin account, can anyone tell me what is wrong and how to fix this?
You could try to open the agent service, and change the Log On account to an Administrator:
I have run this custom action with Installshield Limited Edition for Visual Studio in the past and it has worked. But now when I try this with Installshield 2016, this custom action gives me a 1722 error and rolls back the installation. The log file doesn't give any more detail than "failed with error 1..." and the 1722 error.
My custom action setup via the Wizard -
Working Dir: InstallDir
FileName & Command Line: "[SystemFolder]cmd.exe" /c "[INSTALLDIR]somefilename.exe" "'%r' '%keyname=keyname' '%keydll=some.dll' '%appexe=[INSTALLDIR]differentfilename.exe'"
What this is supposed to do is run somefilename.exe from the command line, with parameters "%r", "%keyname", "%keydll" & "%appexe".
When I run it on the command line directly so -
"C:\Program Files (x86)"\somefilename.exe "%r" "%keyname=keyname" "%keydll=some.dll" "%appexe=C:\Program Files (x86)\differentfilename.exe" - it runs fine.
I think I am missing some quotes someplace and I have tried various combinations with no luck.
Any ideas what I am doing wrong?
Thanks in advance!
Thanks for the suggestions #PhilDW.
I could possibly take out the cmd jacket and just run the exe and try.
I finally got it working though, by changing some quotes etc. Here's what the final FileName & Command Line argument looks like:
"[SystemFolder]cmd.exe" /c start "" /d"C:\Program Files (x86)\foldername\" "somefile.exe" "%r" "%keyname=something" "%keydll=something.dll" "%appexe=C:\Program Files (x86)\otherfilename.exe"
Hope this helps someone.
A few suggestions:
You should post the verbose MSI log section relating to this because it should show the complete resolved command line, assuming that you have created a full verbose log and not a partial log.
It's not clear why you need to run this program with a cmd jacket. If it's a plain Windows program just run the executable as a custom action.
When you run from the interactive user explorer shell you get some infrastructure (such as working directory) that you do not get with a custom action started by an msiexec.exe process. This matters because you have not specified an explicit full path to some.dll, so it's not obvious it can find the file.
It might be useful to say something about where this custom action runs and its type. For example if it's turned into an immediate custom action (all VS custom actions are deferred) then it will fail because no files have yet been installed. Likewise, if it's deferred but somehow before the InstallFiles standard action it will fail.
All custom actions run by Visual Studio generated projects are deferred and run with the system account in a per-system "Everyone" install. If your custom action requires elevation then it must also be deferred and the MSI must show a UAC elevation dialog, because otherwise it may well run but fail with access errors. It may have become a non-elevated per user install.
When I create a new WebAPI project (MVC4) I get the following error.
EntityFramework.5.0.0: Failed to initialize the Powershell host. If your powershell execution policy setting is set to AllSigned, open the package manager console to initialize the host first.
jQuery.1.7.1.1: Failed to initialize the Powershell host. If your powershell execution policy setting is set to AllSigned, open the package manager console to initialize the host first.
After Googling I have found a few answers but nothing that works yet.
Error creating new MVC project - EF and JQuery
This answer seems like it should work for me as my last project was a 7z Command Line app and I might have done something daft with 7zip. But I copy pasted the 7-Zip directory from Program Files to Program Files (86) with no luck.
http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/c934fed4-e44e-4a06-9e3b-eccb9c8aa8d6
There is an answer here that might work (I haven't tried it) but even if it does work I wouldnt want to do this every time I create a new project.
Is anyone able to help me with this one?
I got around a similar error by running PowerShell as administrator with the command Set-ExecutionPolicy Unrestricted, restarting Visual Studio, and opening the Package Manager Console before what I wanted to do.
Make sure you understand the security implications of doing this first.
http://technet.microsoft.com/en-us/library/ee176961.aspx
Restricted - No scripts can be run. Windows PowerShell can be used only in interactive mode.
AllSigned - Only scripts signed by a trusted publisher can be run.
RemoteSigned - Downloaded scripts must be signed by a trusted publisher before they can be run.
Unrestricted - No restrictions; all Windows PowerShell scripts can be run.
I encountered this issue recently, after re-install VS and install the latest VS update 2, things go well. This works for me at least.
I'm having a bit of a problem with Web Deploy I just can't seem to iron out. Every time I try and publish to WMSvc via the [proj].deploy.cmd command in the package I'm getting "The remote server returned an error: (401) Unauthorized". The command looks like this (project is called "Web", server is named "AutoDeploy"):
Web.deploy.cmd /Y /M:https://AutoDeploy:8172/MsDeploy.axd -allowUntrusted
I can publish fine to https://AutoDeploy:8172/MsDeploy.axd via Visual Studio so the service is definitely running and I can successfully authenticate to it as administrator. Running this locally on the machine against the package while logged on as administrator (it's just a little local Win 2k8 VPC) isn't working and adding /U and /P parameters with the administrator account does nothing.
I've enabled failed request tracing and am getting this output so at least there's something to refer to but unfortunately I can't determine what the root cause is. I'm trying to connect to the same service with the same credentials as in Visual Studio but obviously something is different.
Just out of interest, I can publish fine to the Web Deployment Agent Service (MsDepSvc) as follows:
Web.deploy.cmd /Y /M:http://AutoDeploy/MsDeployAgentService /U:AutoDeploy\Administrator /P:...
But I really want to get WMSvc running! Any thoughts?
Sayed's comment above got me pointed in the right direction. After making the build output verbosity "Detailed" and also setting UseMsdeployExe to true in the .csproj (another tip from Sayed's blog), I found the command generated by Visual Studio was setting the authentication type to basic which retrospectively, is obvious given the plain text username and password.
The MSDN post on How to: Install a Deployment Package Using the deploy.cmd File explains you can just add an "a" flag to the command to set this. So in short, here's how it now looks (and actually works):
Web.deploy.cmd /Y /M:http://AutoDeploy/MsDeployAgentService /U:AutoDeploy\Administrator /P:... /A:Basic
Here are the error details:
In the Error List:
Error 1 Cannot register assembly "C:\Users\cboardman\Documents\Visual Studio 2008\Projects\ExcelAddIn1\ExcelAddIn1\bin\Debug\ExcelAddIn1.dll" - access denied. Please make sure you're running the application as administrator. Access to the registry key 'HKEY_CLASSES_ROOT\ExcelAddIn1...' is denied. C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets 3019 9 ExcelAddIn1
In the Build Output:
Target UnmanagedRegistration:
C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(3019,9): error MSB3216: Cannot register assembly "C:\Users\cboardman\Documents\Visual Studio 2008\Projects\ExcelAddIn1\ExcelAddIn1\bin\Debug\ExcelAddIn1.dll" - access denied. Please make sure you're running the application as administrator. Access to the registry key 'HKEY_CLASSES_ROOT\ExcelAddIn1...' is denied.
Done building target "UnmanagedRegistration" in project "ExcelAddIn1.csproj" -- FAILED.
From what I have found online, I need to be running Visual Studio as administrator. This seems like a big hammer for a small nail. Is there a way around this (like a way to run just the registration as administrator)?
Unfortunately there is not an easy way to do this. By default registering the components adds entries to protected keys in the registry (under HKLM in particular). This cannot be done without administrative rights.
It is technically possible to register COM components as a non-admin by using the equivalent keys under HKCU. However it is not a trivial change and I do not believe the .Net tools which register the assemblies can be configured to do this.
I think your best option is to disable registration during build. Then have a separate Admin window open where you can hand register the DLL From for debugging purposes. The re-registration is only really necessary if you change the COM related interfaces or location of the DLL so it doesn't have to be done for every F5.
Closing Visual Studio and re-opening right-clicking on it -> Run as Administrator solved the problem for me.
I had this same problem with Visual Studio 2017.
JaredPar's answer led me to this implementation:
Goto the project's properties
Select Build
Untick Register for COM interop screenshot
Select Build Events
add a Post-build event command line:
for /f %%a in ('dir %windir%\Microsoft.Net\Framework\regasm.exe /s /b') do set current_regasm="%%a"
set command=%current_regasm% $(TargetPath) /tlb:$(TargetDir)\$(TargetName).tlb /codebase ^; sleep 2
set elevated_command="Start-Process PowerShell.exe -Wait -ArgumentList \"-ExecutionPolicy Bypass -Command %command%\"
powershell -noprofile -ExecutionPolicy Bypass -Command %elevated_command% -Verb RunAs"
In the drop-down run the post-build event: select: On successful build screenshot
Run a build
At the end of the build you will see a powershell window run as administrator (depending on your settings you may have a User Account Control (UAC) popup asking you to confirm before it will run).
Note:
This will find the latest .NET framework version and use regasm from there (credit: Scott C).
Increase the ; sleep 2 if you want longer to look at the output to confirm the registration (or use ; pause instead).