I have a setup project, its been working nicely for atleast a couple of years. I have recently added a new project to the mix, a winform. I took me a great deal of googling and research to make it work - many thanks to the loads of articles I found during my "adventure".
This new project enables me to right click a file in Explorer and add it to my system. I can install the project fine, files are being added/copied to their rightfull place. Code is fine, does precisely what I told it to.
For some reason the Registry editor and Windows Registration DB does not agree on keys.
Registry editor states I should have HKCR\*\shell\Add to system\command and a string key saying
Name: (Default)
Value: "[TARGETDIR]mySystemAddFileForm "%1"
Sofar so good, yes Windows reg db also believes the path to be right. Yes there is a "but".
For some reason Windows reg db believes there should be a 2nd string key saying
Name: (Default)
Value: null
The Windows takes precedence and messes up my logic (design, code, idea).
If I manually clean this up, I can right click the files just fine and add them to the system. Just to be clear. Yes, Explorer does have a right click option that says "Add to system" and yes after I edit regedit manually it does work when I click it.
Before I changed it to the Registry editor, I had the key generation in the CustomSetupActions but I couldn't make that handle if the user decided to edit the installation folder. From default [programfiles] (c:\Program Files\ .. ) to whatever the user decided at install point.
By Registry editor I mean the one in the Setup project, View/Registry.
How can I tell Windows to stay the f* of my finely tuned code and let me decide what reg keys are created when and where.
Edited: (Standard) to (Default). Windows may translate the (Default) to the local language. Leave it at Default.
Windows Installer can install default values and usually they are not overridden automatically by Windows.
To install a default value with a Visual Studio setup project, make sure that the Name field is empty: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371168(v=vs.85).aspx
This is usually enough. If the value is not as expected after install, try creating a verbose installation log to see what happens during install. Most likely the registry entry is skipped or written somewhere else.
Related
I'm using pgAdmin 4 (v. 6.12) on Windows 10.
Since (I believe) version 6.10 I've noticed that autocomplete always shows up. I tried to change preferences settings to only show it on Ctrl + space:
But it made no difference - autocomplete is always shown.
Then I've noticed, that some other settings are not respected, for example insert bracket pairs:
This is how editor looks just after typing opening bracket:
This is very annoying. I've completely removed previous installation of pgAdmin: uninstalled it, deleted all files and folders with pgAdmin in name and did the same in Windows registry. But new installation behaves the same.
New installation was made only for my user account, not for Anyone who uses this computer option.
Like you, I was also unable to turn off autocomplete-on-type after installing 6.12.
When using the web client, I was able to log out and log back in to solve it.
UPDATE from comments: using the Windows application, Adam was able to clean session data from the registry, open the editor window, change settings, close editor window, change settings… And it started to work again.
More details...
It happened to me in Ubuntu when I first upgraded to 6.12 and restarted the server, while the client was connected. The web client appears to have held on to a session that at first seemed to work. Once I logged out and log back in, my autocomplete-on-type OFF setting was respected again.
I agree that this bug is completely frustrating. I'm not sure why anyone would want the autocomplete-on-type setting enabled, pgadmin4 is unusable with it on.
My nw.js app suddenly stopped working on Windows 10 with the following error;
Failed to load extension from {path}. Default locale is defined but default data couldn't be loaded.
Structure & manifest
_locales
en
js/i18n.js
Manifest
"default_language": "en"
I don't know what windows has changed recently but it has been working solidly on previous versions of Windows for years. I've updated the country tag as per available language packs for windows here and chromium tags but still no luck.
According to this thread :
"I use Chrome and stopped updating it once they made tabbed-options
mandatory. I also keep my User Data folder in a non-default location.
When this bug started, I used the --single-process trick for a while
but as mwalsher said, it stopped working when they messed with the Web
Store. I used but hate the manual method outlined above, so what I did
was to simply move my User Data folder to a FAT32 partition. Problem
solved; now I can successfully install packed extensions from an older
version of Chromium, running in normal mode, to a non-default User
Data folder. Even better, thanks to a system I set up
(http://superuser.com/questions/196886/how-to-relocate-chrome-profile-but-also-make-new-links-open-with-the-relocated-p/257706#257706),
it was /extremely/ easy to change it (I had only to change a single
byte and reboot)."
..
"Change the security permissions of the temp directory might fix this
problem. On my computer, the temp directory only has 3 full control
user (My Account, System, Administrators) at beginning. I manually
give everyone full control to this folder (maybe adding list
permission only also works). However it doesn't work immediately,
until next day I restart the computer with great surprise.
..
As a workaround, --no-sandbox might work. Note that this is just as
unsafe as --single-process, so be careful when using it.
..
..
perform a "chrome://restart
Try this first:
..I restarted Chrome and tried to install it again, and now it
installed cleanly..
I have a clickonce application which works fine on windows 7.
When it's being installed on a windows 10 machine, it seems that the specific file for our application cannot be properly associated to the clickonce application.
If I click right on the file, and choose "open with", I can see in the list "ClickOnce Application Deployment Support Library". But if I choose this option, I get a message saying "this application cannot be executed on your PC". If I decide to choose directly the .exe file of the clickonce application (C:\Users\xxx\AppData\Local\Apps...), it will not work properly (version & update detection).
I am able to install my application and I am able to run it properly from the start menu. The only thing not working is the file association. I have tried to uninstall, and reinstall, but it doesn't change anything.
Edit :
I have installed the application on another windows 10 machine, and everything works fine (including the file assocation "automatically when installed & when specifiying it manually"). So I think the problem is not "generic" for all windows 10 machines.
I was able to reproduce montueron's issue. After turning on logging (https://msdn.microsoft.com/en-us/library/dd996997.aspx) and setting the logging location (https://msdn.microsoft.com/en-us/library/ms404265.aspx), I was able to determine that the file association was being skipped: File association for ".tiff" skipped, since another application is using it.
Here is what I did to solve my problem on Windows 10. My goal is to associate my ClickOnce program, "Tif2PDF", with .TIF and .TIFF image files.
Create a unique file association in the ClickOnce Publish settings in Visual Studio 2017. I am not using .TIF at this time, we just want to create the appropriate registry entry under HKCU\Software\Classes\Tif2PDF which will get removed in the un-install process.
Properties->Publish->Options->File Associations.
extension=.tif2pdf
description=Tif2PDF
progID=Tif2PDF
icon=Resources\Tif2PDF.ico
In the Tif2PDF program startup process, we need to add registry settings when it is installed - only run when it is updated:
if ( System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed
&& ApplicationDeployment.CurrentDeployment.IsFirstRun )
Computer\HKEY_CURRENT_USER\Software\GuardTech\PDFTool\Capabilities\FileAssociations
.tif="Tif2PDF"
.tiff="Tif2PDF"
These two entries tell windows to use the HKCU\Software\Classes\Tif2PDF entry for TIF and TIFF file types.
Tell Windows this is a registered application. This value points to the key created in step 2.
Computer\HKEY_CURRENT_USER\Software\RegisteredApplications
Tif2PDF="Software\Tif2PDF\Capabilities"
At this point, you should see an option in Windows Explorer under "open with" called "ClickOnce Application Deployment Support Library". It will work at this point, but let's add a label and icon.
Create key and values below.
string iconSourcePath == Path.Combine(System.Windows.Forms.Application.StartupPath, #"Resources\Tif2PDF.ico");
Computer\HKEY_CURRENT_USER\Software\Classes\Tif2PDF\Application
ApplicationIcon=iconSourcePath
ApplicationName="Tif2PDF"
You program will need to handle command line arguments a little differently
//Get the normal command lines arguments in case the EXE is called directly
List<string> argList = new List<string>(Environment.GetCommandLineArgs());
argList.RemoveAt(0); //Remove the application.EXE entry
// this is how arguments are passed from windows explorer to clickonce installed apps when files are associated in explorer
if (AppDomain.CurrentDomain.SetupInformation.ActivationArguments?.ActivationData != null )
{
argList.AddRange( AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData);
}
We should try to cleanup these registry settings when we un-install the program by following thedracle's post Custom action on uninstall (clickonce) - in .NET
I just created a test application as Administrator (Windows Forms Application) using Visual Studio 2015 (< 5 minutes)
1) Under Properties/Publish/Options/File Associations added an entry:
Extension: .abcd
Description: test
ProgID: 2
Icon: An icon file
2) Under Properties/Publish I pressed Publish Now and ran Setup
3) Created a text file, renamed it to test.abcd
It is working as expected under Windows 10, so you could create a test application / verify that it's working and see what the differences are compared to your existing application.. 32/64 bit, framework, signing etc.
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.)
Our lead programmer likes to install tools on a shared network drive to minimize effort when updating. He recently installed Eclipse to the network drive, but when I run it, I get a window that says Workspace in use or cannot be created, choose a different one. After clicking OK, I get a window that gives me a drop down menu with only one item, the workspace on his machine. I can then browse to the workspace on my machine, click OK, and Eclipse continues to start up and run just fine. There's a check box in that second window that says Use this workspace as the default that I've checked after browsing and selecting my workspace, but the next time I start up Eclipse, it reverts back to the lead's workspace.
Are we violating some assumption that Eclipse makes about the install? We're on a Linux network, if it makes a difference.
Setup the shared eclipse such that it can not be modified by the users accessing it. This should (if I recall correctly) force eclipse into a "Shared User, Hands Off" mode and default to storing settings per user account.
Do not share Workspaces (or Projects) -- this will only break things horribly -- use a different strategy such as a proper revision control system.
Perhaps this documentation will be helpful.
"""The set up for this [shared] scenario requires making the install area read-only for regular users. When users start Eclipse, this causes the configuration area to automatically default to a directory under the user home dir. If this measure is not taken, all users will end up using the same location for their configuration area, which is not supported."""
I would try to run Eclipse locally as well as over the network. Using a shared network drive may make Eclipse more painful than it sometimes is. A development environment should work for the developer, even at the expense of a slightly more complicated setup.
Eclipse stores a lot of settings, including the workspace list, in it's installation directory (especially the "configuration" directory). It's hard to say how well sharing the installation will work, but I wouldn't be surprised if there were a number of issues caused by "fighting" between Eclipse instances running on different developer's workstations.
To fix the particular issue you're having, you could set up a separate startup script that passes your workspace as a command-line argument to Eclipse, bypassing the workspace selection dialog you're seeing.