In order to organize some T4-generated files within my solution, and per this excellent answer, I have a .reg file that I use to add a key and three values under the following Visual Studio registry key (currently formulated for VS 2015):
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config\Projects\{FAE04EC0-301F-11d3-BF4B-00C04F79EFBC}\RelatedFiles\
Periodically and intermittently, I find that this key has been overwritten and I must run my .reg file again to restore my custom Visual Studio behavior. I have seen this happen every few months or so, for many years, across several versions of Windows and VS, on many machines, and three different domains (on one of which I am sole admin). There's no obvious (to me) temporal association between the overwrites and either Group Policy or Visual Studio Updates, so my best guess is that either Visual Studio is periodically performing some sort of self-"repair", or else certain Windows Updates are overwriting these keys for some reason.
What mechanism is likely causing this (or how could I go about detecting it myself)?
More importantly, what method would be the best practice to either prevent the overwrites or automatically "repair" them when they do disappear? I know I could probably use group policy (where I am a domain admin) to force the registry entries, but I don't have GPO admin rights at every site where I work, and I'd prefer an option that was less ServerFault-y and more StackOverflow-y, particularly because I haven't yet identified the root cause.
You can think of the 14.0_Config key as a volatile cache of VS’s
configuration data for a particular user. It is simply the combination
of HKLM\Software\Microsoft\VisualStudio\14.0 and any pkgdef files
coming from VS extensions.
Source: All Your RegKeys Are Belong To Us
So, in addition to 14.0_Config you can try to add your registry data to the 14.0 key.
Related
Why does TFS only merge files and Comments when there can be an arbitrary number of additional fields? Can this behavior be changed?
Our check-in policy requires these other fields to be set, but having to manually copy them over defeats the purpose of using automation (the merge tool).
Also, if I preemptively have any of these fields manually copied over, those are then deleted (even when identical)... So because I tried to manually associate the work items I knew it wouldn't for me, it unset them, so I have to do it yet again.
This applies to both VS 2015 and 2017, on TFS 2015
It is what it is. The behavior you want is not how it was implemented.
There are a couple of extensions on the marketplace that add some of what you want:
https://marketplace.visualstudio.com/items?itemName=AdamLove.MergeChangeset2019
https://marketplace.visualstudio.com/items?itemName=KulikovDenis.AutoMergeforVisualStudio2017
https://marketplace.visualstudio.com/items?itemName=DieterVantilt.teammerge
The idea is that by following the merge tree you can derive the information. Why would you duplicate the content from one commit to another?
As you can see Team Explorer is extensible, creating or extending one of these existing extensions to match your process is entirely possible.
We have some legacy Classic ASP websites to maintain, and are wanting to use VS2010 to edit them, due to familiarity because of lots of .Net work.
I can open the website inside Visual Studio.
I can configure IIS to run the website based on the working folder used in VS2010.
I can configure VS2010 to automatically open my default browser pointing to the correct location, using the 'Base Url' setting in the Properties page.
What I CAN'T do, is work out where VS2010 stores this value, as there's no mention of it in the solution file that VS2010 has created, and as there's no project file for the website, there's nothing there too. Yet, when I close and re-open VS2010, it somehow retains this information.
This is important to me, as I need to be able to commit all files to our source control for use by other developers and, ideally, not have them worry about setting this value themselves.
So, the question is: Where does Visual Studio 2010 store the Base Url when working on Classic ASP websites?
I don't know where this is saved, but in tracking things like this down in the past I typically take the following approach:
Open Visual Studio and change this one setting
Apply the changes
Look for all files that have been modified in the last 1 minute in the project folders and in the Visual Studio folders
You can be sure there will be at least a few other files changed that are not relate to this, but it should narrow your search. You may want to re-close VS before searching too, but that will modify other files as well (making for a slightly larger pile of changed files to sift through).
If you still don't have it, search the registry (but I cannot imagine this would be where it was storing anything project specific).
EDIT:
Just created a new project and played with setting this property. It is definitely stored in the .suo (Solution User Options) file for the project, in the root of the project folder as #Lankymart suggested (and is a hidden file if you are not seeing it). It is not stored in plain-text.
You may be able to access it programmatically here: http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.shell.interop.ivspersistsolutionopts.loaduseroptions.aspx
As there are a ton of absolute path settings in these files, moving it to other environments is not really an option. I would suggest you are stuck with project start up documentation that lists these settings as part of the project setup process. I think any other solution is going to be equally annoying|fragile (or worse).
Not sure if there is another way to accomplish what setting the base URL does without managing from the Start Options panel - that is likely your last-best hope for a solution.
This should be pretty simple, but I can't seem to get it. I have a setup project (VS2010) that packages a few dozen image files (along with my SQLite file) and copies them to the user's computer when the program is installed. As these are essentially "stock" images, it's ok if the user deletes them (there is functionality to do so from within the program.) However, after one or more of these images have been deleted, the next time the program starts it gives a "Windows installer" dialog box, and deletes all of the remaining data files!
What I think is happening is the program sees the missing files, assumes the installation has been corrupted, and tries to go into some kind of recovery/uninstall mode. I'd like to know how to indicate in the setup project that the files need to be installed, but may be removed by the user at any time.
I have tried several combinations of File properties, and nothing seems to do quite what I want, which is for my installer to put them where I say and never think about them again. Do I have to reinvent the wheel and do this through a custom action??
EDIT: Transitive and Vital had both been set to True. Setting them to False causes the program to re-add the deleted images back after it has been restarted! I'll probably go with a custom action if I don't get an answer.
When using a file association or advertised shortcut Windows Installer automatically checks if component key paths are missing. If a key path is not found, a repair is trigger to reinstall the component.
Most likely your installer repair process does something that removes the other files.
A solution is to not register your components with Windows Installer. This is done by using a null component GUID and it's not supported by Visual Studio setup projects (it is however supported by most of the other setup tools).
Another solution is to make sure that your image files are not key paths in their components. This is also not supported by Visual Studio.
If you want to use a setup authoring tool which offers more control, you can take a look at this list: http://en.wikipedia.org/wiki/List_of_installation_software
I have issues setting up my deployment project in Visual Studio 2010. Im using Windows 7 x64. Here's my problem:
The setup is supposed to install my program for all users. During the setup three registry keys are written to the HKEY_LOCAL_MACHINE/Software/Something folder, containing the setup variables for Serial, Name and Organization as values - [COMPANYNAME], [PIDKEY], [USERNAME].
What happens:
User1 (Admin) installs the software, entering his username, serial and company. Everything works. The keys can be found and values read by the program, using Registry.LocalMachine.OpenSubKey(path). The first thing I don't get is that I cannot find the registry entries, using the regedit.exe. Anyway, the code above finds them.
Now, User2 (Non-admin) tries to execute the freshly installed program. The installer is launched again, saying "Wait for ... to configure ...". The user specific folders for User2 are created correctly. The program is started, but the registry keys cannot be found by the program anymore.
Now, finally, User1 tries opening the program again. (The registry entries cannot be found anymore.) Edit: The registry entries are actually there, but its values are empty.
So, my questions:
Why can't I see the registry entries with regedit after the install, although they are obviously there?
(2. Why are the registry entries deleted, when the second user tries launching the program for the first time and how can I avoid that?)
Edit:
2. Why are the registry values set to empty strings, when the second user tries launching the program for the first time and how can I avoid that?
Cheers from Auckland and thanks!
Marc
You might be missing the registry entries if you have a 32 bit package installed on a x64 machine. In this case the registry entries would be redirected under "HKLM\Wow6432Node...". This is the standard behavior for x64 Windows machines. The same happens with the file redirection to Program Files and Program Files(x86).
That is strange. It could happen that the second launch of the installer, a normal automatic repair operation, has removed the registry entries by mistake. To get more details about the actions executed during the second launch I recommend you enable permanent logging on the OS.
http://support.microsoft.com/kb/223300
Wonder why the Find-function didn't find the keys though?
Probably the API used is considering the keys do not exist if all the values are empty. You should check its docs.
Obviously the "second installer" performs the entry again, without having values for that. Do you have an idea how to solve that?
This usually happens if the registry are written with values from public properties. During the automatic repair the properties don't have their initial install values so they are considered to contain an empty string, which is than used to replace the registry values.
The only solution you have is to make a small custom action that runs during repair, as immediate, which searches the registry entries before they get overwritten and places their values in the properties your are using. This way the overwrite operation will use the correct values.
I have 2 msi files that I run silently one after the other from win forms application (master installer for that matter). Both of them configured to write to registry to same location,
for example:
HKLM\Software\MyProduct\MSI1
HKLM\Software\MyProduct\MSI2
Now, I run uninstall in reverse order and when uninstall done, MSI1 removed from registry, but MSI2 is stuck there... Is there anything can be done about that without custom action or coding?
This happens because your registry entries use the same component as another product installed on the machine. For example, you copied the setup project of an existing product and used the copy to create an MSI for a different product.
To avoid it, you need to make sure that each MSI uses unique component names and GUIDs. It's not easy in Visual Studio setup projects. You can try editing the project file. If it doesn't work, it's better to start from scratch with a new setup project.
Ok, I found problem in VS2010 (Big Thanks to Cosmin Pirvu) and just will go on and put here the 2 solution options I see so far. But first, the problem:
As I mentioned I have 2 entries:
HKLM\Software\MyProduct\MSI1
HKLM\Software\MyProduct\MSI2
But in code, they look the same because MSI1 and MSI2 being "place holders":
HKLM\Software\MyProduct[ProductName]
So, the name is identical and properties identical this is why we get same component id for both!
Two things (as far as i see) you can do:
Instead of [ProductName] enter actual product name (hard coded)
(What I did is) In registry entry property, in condition field, enter meaningless string (make it really meaningless, so it wont meat reasonable condition, i used guid with leading __).
Thanks for all answers