I developed an Outlook 2003 add-in which uses the com dll redemption. I created a visual studio 2008 setup project, added a custom action to run "caspol.exe -machine -addgroup 1 -strong -hex [key] -noname -noversion FullTrust -n \"Name\" -description \"desc\" and moved the registry keys under software to HKLM as described in http://msdn.microsoft.com/en-us/library/cc136646.aspx#AutoDeployVSTOse_InstallingtheAddinforAllUsers to ensure all-users compatibility.
I included the redemption.dll in the setup with vsdrfCOMSelfReg (vsdrfCOM throwed an error).
My problem is: When installing the setup on a test machine under an admin account, it runs fine under all users, however when we use the company wide software deployment which runs under a system account the setup executes but the add-in wont load. If I repair the installation with an admin account again it loads just fine. Shouldn't a system account have the required permissions to install all of the components? What options do I have?
Thanks for any suggestions.
After the install runs under the system account, do you see the Redemption registry entries in HKCR? E.g. HKEY_CLASSES_ROOT\Redemption.RDOSession ?
After some endless nights I finally figured out the problem. It really was all about Code Access Security and the caspol.exe
Some tips for deploying Outlook 2003 Add-Ins (Outlook 2007 is different).
First of all, on your test client, be sure to set the Windows environment variable VSTO_LOGALERTS=1, since this will write all the errors of the Add-In to a log file which is located in your target install directory. It is also very important to know, that if your Add-In throws an exception during startup, it will be disabled in the registry on the next launch of Outlook (see here What can cause Outlook to change a COM-addin's LoadBehavior to 2 - other than unhandled exceptions?). This can cause some confusion when you're not aware of it.
Now let's move on to the caspol problems. Be sure to sign your assemblies with a strong name key first. Next, you need to make sure that your assemblies gain full trust on the client. To do this you may run the caspol.exe with the following settings: "caspol.exe -machine -addgroup 1 -strong -hex [key] -noname -noversion FullTrust -n \"Name\" -description \"desc\". With these arguments, you will give all the assemblies signed with your key earlier, full trust on the machine. This is way better than giving a whole directory FullTrust.
In a production environment, you will certainly want to create a setup for your Add-In. You might also create a custom action for your setup project to do all the caspol stuff automatically. You can use the sample code provided here "http://msdn.microsoft.com/en-us/library/cc136646.aspx#AutoDeployVSTOse_CreatingtheCASPolicy" but watch out: Check for -pp off in the caspol arguments. If the policy change prompt is on then you're automatic installation will fail since it requires user interaction. set -pp to off, execute the policy and set it back on. Watch out again: The sample code does not wait for exit of the process.
After I figured all that out, the deployment of the Add-In was easy, even for an "all users" installation. Hope that helps anyone out there.
Related
Whenever I try to get my developer's license in Windows 8 Professional with WMC for Visual Studio Ultimate with Blend, I get this error:
We couldn't get your developer license for Windows 8. (Error 0xC03F1014)
How do I fix this error to get my developer's license?
If your copy of Windows 8 is cracked or activated illegitimately then you'll get this error.
If for whatever reason you don't want to / can't get a legitimate copy, then deactivating the crack to go back to the trial period, acquiring the license then re-activating it should fix this issue.
Try to follow these steps:
Create a temporary user account in windows 8
Install a fresh copy of VS 2012
Now try again. It should work now, then log out again and go back to your normal account. Now develop apps and deploy it. Hopefully it works for you.
You need not re-install the OS or the Visual Studio
Start the Task Scheduler service. This is usually disabled in enterprises/large organizations via Group Policy.
This situation happened to me after installing Windows 8 Pro Upgrade as a CLEAN installation. The problem was that the valid License Key failed to activate because a previous version of windows was not upgraded. Because it wasn't activated properly, the Developer License would also not register.
The following steps enabled me to activate the clean install:
Run the registry editor (regedit)
Find the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OOBE
Change the value for 'MediaBootInstall' from 1 to 0
Open an elevated command prompt (run as admin)
Run the following command: slmgr -rearm
Reboot
Open an elevated command prompt (run as admin)
Run the following command: slui 3
Activate your valid Window 8 Pro Upgrade License Key
After my Windows 8 was properly activated, the Developer License renewed with no problems!
I was facing same issue. Error was due to Proxy Server. I was using internet by setting proxy server. U should have open internet to get the developer license.
See these type off error occurred to me . The scenario was I was connected to a proxy server and my proxy server was not allowing popup logins .
Check your internet connection and If the problem is not solved, reinstall VS
Run Visual Studio 2012 as administrator. It should prompt you automatically for the license. I had to login to my MSDN account at this time. If it doesn't come up, then go to Project -> Store -> Acquire Developmer License. This is what did it for me.
I had the same issue, with the additional information that there was a problem with the network (even though my network was fine).
For me, the problem was that my own user is a limited/normal user and doesn't have administrator rights. I did get a UAC prompt when I tried to get a license and I elevated the process to use my separate administrator account, but it didn't work.
What did work however was logging out from my normal user, signing in as my administrator account and try to get a developer license that way.
So apparently running under a non-privileged user is not something that VS2013 appreciates in scenarios like this. I'm not sure why there is a difference between elevating a process' rights through UAC and actually logging in as an elevated user.
Make sure you have all Windows Updates installed. If you can't update:
Install KB2913270 (x86/x64) (original info by Ahmad Wahid, thanks :))
Other tips:
Check the system date and time (it must not be ahead on their systems)
Try to disable NlaSvc service (Network Location Awareness)
When try to debug the VB dll Using Visual Studio 6.0 , I am getting the the following error. Can you any one tell me what needs to be done for this?
System Error &H80004015 (-2147467243).
The class is configured to run as a
security id different from the caller
I have had the same problem.
Created a few ActiveX DLLs and put the binaries into a COM+ Application, which runs under a specific account (not mine). Then I use these components inside ASP script pages using Server.CreateObject().
If I load the source code into VB for debugging and try to run it ("Start with Full Compile") I get this error message.
The cause of this is that the account registered in the COM+ Application differs from my own account from which I try to run.
Solution for this particular case is to Shutdown the COM+ Application and remove the components. When finished debugging, compile the set of DLLs and put them back to the COM+ application.
Hope someone is helped by this :-)
My solution was to unreference the dll in the Visual Basic project (Project Menu -> References), close the dialog box and reference it once again. I ran the project and everything is working again. I did not have to edit the windows registry.
There's a knowledge base article that seems to apply to your situation:
PRB: System Error Message "&H80004015" When You Run ActiveX DLL in Visual Basic IDE
Cause: When Visual Basic runs an ActiveX DLL from the IDE, it calls the CoRegisterClassObject application programming interface (API) to temporarily register the server. This creates the AppId and specifies it to run in the Interactive User context.
This problem occurs because of a bug in the Microsoft OLE Libraries 4.0, which are included with the Microsoft Platform Software Development Kit (SDK). CoRegisterClassObject fails with the error message that is listed in the "Symptoms" section of this article under the following conditions:
If the ActiveX server that calls the API is set to run by using the Interactive User identity.
-and-
The string that is associated with the following registry key contains any value other than a single valid executable name for the shell process:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Shell=
Under Microsoft Windows 2000, this error occurs when the Certification Authority service does not start.
Resolution: Make sure that the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Shell= registry key contains a single valid executable name for the shell process.
To resolve this problem under Windows 2000, you can install the "Client for Microsoft Network" component and then reboot.
This is the error that is thrown by our automated build suite on Windows 2008, while running ICEs (after migrating from WiX 2.0 to WiX 3.0):
LGHT0217: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.". in light.exe(0, 0)
The FAQ is now deleted, however, the text from it said:
In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.
Additionally, these are the errors that show up in the event log:
MSIInstaller: Failed to connect to server. Error: 0x80070005
Product: [ProductName] -- Error 1719. The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.
Intuitively:
VBScript and JScript were registered under admin.
Integration service has permissions for the desktop interaction and all the files
Builds succeed, when executed manually on the same machine by another user or even user logged in as integration account (via RDP)
I'm out of ideas so far.
How do I solve this problem while keeping ICE validation?
End of the story:
After fiddling with the permissions of the integration account, DCOM, service activation, etc. without any luck, I finally simply disabled ICE validation in the continuous integration build, while still keeping it in the local build.
To disable ICE validation you can set SuppressValidation to true in the .wixproj file:
<PropertyGroup>
<SuppressValidation>true</SuppressValidation>
</PropertyGroup>
Or pass the -sval command line option to light.exe.
Adding the TFS build controller account to local admin group and restarting the windows service did the job for me.
I found the root cause. I tried everything I found, including custom validator extension similar to one posted in Re: [WiX-users] light.exe failed randomly when running ICEs..
It's not a concurrency issue as suggested in various threads. It's caused by a too large Process Environment Block (PEB).
It turns out Windows Installer can’t handle a process environment block larger than 32 kB. In my environment, due to number of variables set by the build system and their size (for example, PATH variable containing multiple duplicated values), PEB was about 34 kB.
Interestingly, per Environment Variables, Windows XP and 2003 had a hard limit of PEB set to 32 kilobytes. That would probably cause an easy-to-catch build break in an earlier phase of the build. Newer Windows' doesn’t have such limit, but I guess that Windows Installer developers limited their internal environment buffers to 32 kB and fail gracefully when the value is exceeded.
The problem can be easily reproduced:
Create a .bat file which sets environment variables which size exceeds 32 kB. For example, it can be 32 lines of set Variable<number>=<text longer than 1024 characters>
Launch cmd.exe
Execute the batch file you created
From the same cmd.exe window:
Try building the MSI package using WiX with ICE validation on OR
Run smoke.exe to validate your package OR
Simply run msiexec /i Package.msi
All the above commands will end up reporting Error 1719 - Windows Installer could not be accessed.
So, the solution is - review your build scripts and reduce number and size of environment variables so they all fit into 32 kB. You can easily verify the results by running:
set > environment.txt
The goal is to get file environment.txt smaller than ~30 kB.
The correct description (without a solution, except if adding the CruiseControl account into local administrators group can pass as a solution) of the problem:
Quote from Wix 3.5 & Cruise Control gives errorLGHT0217:
ICE validation needs an interactive account or administrator privileges to be
happy. See for example WiX Projects vs. TFS 2010 Team Build (2009-11-14) or Re: [WiX-users] Help with building patch (2009-11-20).
imagi is totally right! I could not believe this is the true answer. Supressing validation and making TFS user Administrator are not good solutions. Plus I could not find NT\Authority to add it to Administrators group and was totally stuck in this.
I got the same error on Windows Server 2012 Datacenter as Build Agent.
To solve the problem :
List item
Go to Environment Variables on the build agent machine
Create two System Variables
"PF86" which is equal to "C:\Program Files (x86)"
"PF" which is equal to "C:\Program Files"
They are so short because I want to save characters.I made them without the final backslash because TEMP, TMP and others were made so and I decided to stick to MS standard for these variables.
Edit PATH variable by substituting every "C:\Program Files (x86)" with %PF86% and every "C:\Program Files" with %PF%
Close and build and enjoy!
It worked for me. :)
UPDATE
I found a better solution : Rapid Environment Editor will do all this and even more for you. Automatically.
I faced the same problem and did not like to suppress ICE validation. My setup: I used my own computer as a build agent on Visual Studio Online (VSO). My solution was to change the account used to run the service on my machine. Instead of using Network Service or Local Service I simply made the service log on with my own account which had all the necessary rights.
From http://wix.sourceforge.net/faq.html#Error217:
In WiX v3, Light automatically runs validation--
Windows Installer Internal Consistency Evaluators (ICEs)
--after every successful build. Validation is a
great way to catch common authoring errors that can lead to service problems,
which is why it’s now run by default. Unfortunately, there’s a common issue
that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to
fail. For details on the cause and how to fix it, see
Heath Stewart's Blog
and
Aaron Stebner's WebLog.
I was getting same ICE error, but the problem turned to be corrupted Windows Installer Service.
This solution worked for me:
http://support.microsoft.com/kb/315353
Log on to your computer as an administrator.
Click Start, and then click Run.
In the Open box, type cmd, and then click OK.
At the command prompt, type msiexec.exe /unregister, and then press ENTER.
Type msiexec /regserver, and then press ENTER.
Restart Windows
Also, verify that the SYSTEM account has full control access permissions to the
HKEY_CLASSES_ROOT hive in the Windows registry. In some cases, you may also have to add Administrator accounts.
I have some suggestions.
Try updating the Microsoft Installer version on the build server
Make sure you use the newest release of WiX 3.0, since it's 3.0 release stable now.
If all else fails, try running the build service under a specific build user who you can fiddle with permissions for...
I got this error from my Azure build agent running on-premises.
My solution was to upgrade its user account from "Network Service" to "Local system account".
Go to your build machine and restart the Windows Installer service
None of the above suggestions worked for me, for me the anti-virus (mcafee) came into the picture and looks like it updated the vbscript.dll registry entry to a wrong DLL location. These are the things to keep in mind:
Some of the WiX ICE validations are implemented using VBSCRIPT.
So while compiling the MSI, the build server would need access to the c:\windows\system32\vbscript.dll.
Chances are that somehow the user that runs your build lost access to this DLL.
As mentioned in the above answers do look for the admin access/registry access and make sure your user has it.
Here are the steps that I took to fix the issue:
Open cmd (run as admin) on the build agent machine.
Run RegEdit
Select the root, then click ctrl + f and Search for the following registry entry : {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
Look for the InprocServer32\Default Key
On my build agent, the path was replaced with a mcafee DLL location. I updated the path back to c:\windows\system32\vbscript.dll
Editing the registry entry was not easy, as it was a protected registry entry. I used the below link to get access permissions changed before I could edit the property: Edit protected registry entry
Once I updated the path, everything started working as usual.
My solution is similar to Vladimir's one. My CI user was admin of the computer.
But the following steps were mandatory to allow my jenkins build to succeed:
log in as CI user using rdp
open a dos command prompt
execute: %windir%\system32\msiexec.exe /unregister
execute: %windir%\system32\msiexec.exe /regserver
then i got a successfull job
In Visual Basic 6, when I attempt to access Project > References, it throws an error:
Error accessing system registry
I am:
Logged in as the local computer administrator
running Windows XP Professional and
I can execute regedt32.exe and access all the registry keys just fine.
VB6 was installed as the local administrator.
Any idea why this happens?
I'm running crystal reports 8.5 and it supposed to already have fixed that issue but apparently I still have the issue with 8.5 installed. I have also made the attempt of reinstalling crystal reports with no luck on the issue.
Depending on the Windows OS you have (I have Windows 7 Enterprise), you might want to try giving administrator rights to the REGTLIB.EXE (located in C:\Windws). Right click on the REGTLIB.EXE file. Select Properties from the pop-up menu. Then select the Compatiblity tab. On the Compatiblity tab, check/select the Run this program as Administrator checkbox. Click OK to save your changes. It might take take care of the problem for you. It worked for me. Good luck.
For me this worked:
goto C:\Program Files\Microsoft Visual Studio\VB98
change the property of VB6.EXE by right click->Compatibility In privilege level section, check the option Run this program as Administrator
If you're running Office 2010 (Beta) Word (apparently) writes a restricted registry key. VB throws the error when scanning the registry. The key I have is:
HKCR\TypeLib\{00020905-0000-0000-C000-000000000046}\8.5
For Regmon - Filter for Process Name -> "vb6.exe" and Result -> ACCESS DENIED. Helps find it very quickly.
Fixed it with PSToosl (PSEXEC) to run registry editor. The command line is,
psexec -i -d -s c:\windows\regedit.exe
psexec needs to be run with elevated-permissions.
Edit by Jim: I'm on a Windows 7 (x64) box. Elevated permissions require the PSTools solution. XP can get away with a little less.
You could try Process Monitor to see which registry keys are accessed.
I got this on a machine that I was using for VB6 development. I had been building a lot of COM DLLs from VB6 (without binary compatibility) and the cruft that had built up in the registry eventually got too much.
Have a look at what size the registry is and what limit you have set. I doubled the registry size and then went looking for a good registry hoover.
Here is a solution from Microsoft. It references the Crystal Reports problem, but the solution just uses regedit32 to walk the HKEY_CLASSES_ROOT\TypeLib and HKEY_CLASSES_ROOT\CLSID registry branches for dimmed keys and correcting the security on those keys. There are also instructions to fix the security if regedit32 is unable to access the key. Article ID: 269383
In Windows 7 go to start menu then right click "Microsoft Visual Basic 6" then select properties and click Compatibility from the dialog box that appears then tick "Run this program as an administrator".
Have you tried this? Basically, it seems that it is a crystal reports issue. Hope that helps.
Perhaps worth a try going to the "User Account Control Settings".
Regards,
When I installed VB6 on Win7-64 (using instructions easily found by a search engine), it worked fine. UAC was off -- i.e. set to "never notify."
After a few weeks I turned UAC on -- i.e. set it to its default. VB6 then couldn't compile because of the "Error accessing the system registry" problem. Unfortunately, turning it off again didn't help. Apparently the damage done by turning it on was irreversible. I can't explain why this should be, but that's my experience.
Giving REGTLIB.EXE administrative privileges while leaving UAC off sounded like a great idea, but that didn't work for me either.
Finally, using Process Monitor and PsTools as described in other posts here worked. However, I had to give Full Control to large parts of my registry to Everyone. This didn't apply just to isolated keys. It seems that the compiler needs to add keys to major nodes, so I had to open up these entire nodes.
Aside from the fact that working through these steps took hours, I'm now much more exposed than I was before I tried to increase security via UAC, However, I need VB6 and don't see another solution short of a new computer.
Lesson: Don't use UAC with VB6. Except if you've arrived here it's too late for that.
It's VB6 installation issue. Try to re-intall VB6 on your system. Otherwise open "visual studio 6.0" with "Run as Administrator". Then open/browse your project .vbp file via - New Project -> Existing tab.
I have fixed the problem. But none of the suggestion above worked. What I did is giving everyone full control over the SYSTEM key in the registry. This creats a security break. I am running 64bit Windows 7 with vb6 serice pack 6B.
I'm running Windows 10 Pro (10.0.16299 Build 16299) 64 bit. I was having this error when trying to compile a VB6 DLL.
I saw several answers in this post about running in compatibility mode as administrator. I thought I would first try just running in compatibility mode for Windows XP (sp2). I was able to compile my DLL after checking that box. I didn't need to run as administrator.
When creating a setup/MSI with Visual Studio is it possible to make a setup for a simple application that doesn't require administrator permissions to install? If its not possible under Windows XP is it possible under Vista?
For example a simple image manipulation application that allows you to paste photos on top of backgrounds. I believe installing to the Program Files folder requires administrator permissions? Can we install in the \AppData folder instead?
The objective is to create an application which will install for users who are not members of the administrators group on the local machine and will not show the UAC prompt on Vista.
I believe a limitation this method would be that if it installs under the app data folder for the current user other users couldn't run it.
Update:
Can you package a click once install in a normal setup.exe type installer? You may ask why we want this - the reason is we have an installer that does a prereq check and installs anything required (such as .NET) and we then downloads and executes the MSI. We would like to display a normal installer start screen too even if that's the only thing displayed. We don't mind if the app can only be seen by one user (the user it's installed for).
ClickOnce is a good solution to this problem. If you go to Project Properties > Publish, you can setup settings for this. In particular, "Install Mode and Settings" is good to look at:
The application is available online only -- this is effectively a "run once" application
The application is avaiable offline as well (launchable from Start Menu) -- this installs the app on the PC
You don't actually have to use the ClickOnce web deployment stuff. If you do a Build > Publish, and then zip up the contents of the publish\ folder, you can effectively distribute that as an installer. To make it even smoother, create a self-extracting archive from the folder that automatically runs the setup.exe file.
Even if you install this way, if you opt to use it, the online update will still work for the application. All you have to do is put the ClickOnce files online, and put the URL in the project's Publish properties page.
Vista is more restrictive about this kind of thing, so if you can't do it for XP you can bet Vista won't let you either.
You are right that installing to the program files folder using windows installer requires administrative permissions. In fact, all write access to that folder requires admin permsissions, which is why you should no longer store your data in the same folder as your executable.
Fortunately, if you're using .Net you can use ClickOnce deployment instead of an msi, which should allow you to install to a folder in each user's profile without requiring admin permissions.
The only way that I know of to do this is to build a ClickOnce application in .NET 2.0+
If the user of your application has the correct pre-requsits installed then the application can just be "launched".
Check out:
Microsoft Family.Show
IF UAC is enabled, you couldn't write to Program Files. Installing to \AppData will indeed only install the program for one user.
However, you must note that any configuration changes that require changes to the registry probably(I'd have to double check on that) administrator privilege. Off the top of my head modifications to the desktop background are ultimately stored in HKEY_CURRENT_USER.