I'm creating a single file generator for Visual Studio (similar to the LINQ to SQL/ LINQ to Entities generators). I've follewed the example in the Visual Studio 2008 SDK (http://code.msdn.microsoft.com/sfgdd), but I've hit a snag with regpkg, I can't work out how to get it working.
I can't find any good example of how it needs to be done, the examples seem to think I have a .reg file already, but I don't know what I need in the .reg to do it.
Can someone fill in the gap in the examples documentation?
I've managed to solve the problem, using an Installer project within Visual Studio to set up the registry keys. In addition to that you need to have the DLL installed into the GAC.
I'll be doing a series on my blog which covers this, starting with the registry keys: http://www.aaron-powell.com/blog/june-2009/creating-an-installer-for-a-single-file-generator---part-1.aspx
Related
I rely on the Find in Files dialog in Visual Studio a great deal. (Sometimes Intellisense/Resharper just don't cut it.) Since upgrading to 2015, I've noticed that the dialog doesn't remember my custom "Look in" paths or "Look at these file types" lists between sessions.
If I close my solution and VS instance, then reopen, I have to enter my custom path and file types again. Huge waste of time. Has anyone run else run into this? Any workaround? 2013 used to remember this stuff.
Microsoft Visual Studio Professional 2015
Version 14.0.23107.0 D14REL
Microsoft .NET Framework
Version 4.6.00081
Installed Version: Professional
I've never had any problems with it not remembering my settings, but I imagine that you could run a custom registry modifier to add the appropriate keys, you could make sure your settings are always pristine. The custom search information is stored in HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0\Find.
The file types are stored in a string key called Filter with whatever you would normally input into the custom file type category in the VS search window. For example searching for only .cs and .txt files you would put *.cs;*.txt.
The folders are located in a string key called Query with values such as C:\Folder1;C:\Folder2. However, it's behavior seems a little weird. You have change the value of Query and a Query+integer value (i.e. Query0) to the same value to have it appear in Visual Studio.
If you just run a script to modify the above values to the files types/folder locations you want, that should work.
I ran into this today. After much searching I found a post on the visual studio forums somehow. This pointed me towards ReSharper. This directed me towards a workaround.
Start visual studio in safe mode with the command line argument /SafeMode
Create the folder sets you want for searching
Restart visual studio not in safemode
Once I had restarted all my created custom searches remained, and the registry values were created. This might not work in the specific case, but this worked for me.
You can set these values programmatically inside Visual Studio for the Find and Replace dialog (for example with Visual Commander):
DTE.Find.FilesOfType = "*.txt";
DTE.Find.SearchPath = #"c:\temp";
If you have an earlier version of VS, export the environment settings, copy the NumberOfScopes and NamedScopes* settings from the Environment_UnifiedFind section to the same section in your VS2015 settings file and then re-import settings.
Once I did this, it allowed VS2015 to start saving folder specifications for future settings exports.
Or you could try replacing this in your VS2015 export:
<PropertyValue name="NumberOfScopes">0</PropertyValue>
With this:
<PropertyValue name="NumberOfScopes">1</PropertyValue>
<PropertyValue name="NamedScopes>0">FOLDER_SPEC_NAME>SEMICOLON_SEPARATED_LIST_OF_FOLDERS>{4A812F3C-7B1A-4987-9769-461F20EB25CB}</PropertyValue>
(Don't forget to re-import after you make the change)
I have a solution with several projects that have Register for COM Interop checked.
I have a Visual Basic 6 project that references the resulting TLBs. One issue with VB6 is when it references a dll/tlb, it puts a lock on that file.
Using Visual Studio 2010, unless I'm doing a rebuild or have made a change to one of these interop projects, I can build/run the solution (with the VB6 project open) without it barking that one or more of the assemblies is locked.
However, using Visual Studio 2012, even on a simple build where nothing has changed, apparently it always does the regasm, which makes it impossible for me to debug my VB6 project.
Is this new feature of Visual Studio of running regasm on build something that I can turn off?
EDIT: Allow me to simplify:
Using Visual Studio 2010, I hit Build-->Build Solution and check the output for one of my assemblies that is marked as Register for COM Interop and the file has not changed.
Using Visual Studio 2012, I do Build-->Build Solution and check the same assembly, it has been updated, and does so every time I hit Build Solution.
I want the behavior in Visual Studio 2012 to work the same as it did in 2010.
EDIT (again):
I posted this to Microsoft Connect. If someone answers it there or posts a workaround, I'll urge them to also post the answer here.
I've always encountered problems like this when running VB6 and VS20XX, but I always did a rebuild. My suggestion is to stop using VB6 for testing purposes. I found it was far easier to simply create a testing project and do all of my testing in .NET on my .NET code. This should only require a small amount of set up, but it is well worth it in my opinion.
I know this isn't an answer to your specific question, but it offers an alternative. As far as the problem you are describing, I can't duplicate a change in behavior. I start off with only VS201X open, full solution rebuild, open VB6 and add a reference to an exposed COM DLL. I didn't notice anything unexpected.
Build works fine as long as I haven't changed anything in the COM DLL
Build fails if I changed the COM DLL's code as the file is locked
Rebuild fails as the file is locked
Custom debug visualization in visual studio:
Is there any way to do it per project instead of editing the "global" autoexp.dat?
Would be nice if it tagged along when changing workstation..
No: per-project (or per-user) visualizers in Visual Studio 2010 (C++ native) are not possible. Visual Studio 2012 added this feature; it is based on "natvis" XML files.
Rather old question, but lets give my cent:
For VS2008 SP1 and VS2010 you have the alternative to use your custom file, instead of invasively edit the native autoexp.dat file using the _vcee_autoexp environment variable.
Credit to: https://vtk.org/Wiki/ITK/Debug_Visualizers_for_Visual_Studio
Note: I have not tried, but maybe using a relative path VS loads it based on the solution folder. Alternatively I would also try using multiple path separated with semicolons. Just give it a try.
Assuming I want the newest flavour of visualstudio that is able to open C# projects, and if there are multiple (pro/express), I'd like to open pro.
edit: I want my own program to open visual studio on the computer of my program's user.
Is this the sort of thing that would be changing with great frequency? If not, I'd just do a search on your PC for "devenv.exe" (the VS executable) and then associate *.cs, *.csproj, *.sln, etc. files to open automatically with the "newest flavor" found that you want to use.
Edit: You could try having your program check the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio registry entry and retrieve the latest version from there, then have your program open the file using the Visual Studio executable at the appropriate location.
There isn't one API available that will simply open the latest version of Visual Studio. This is especially true when you start to consider the impact of expression versions of Visual Studio (and the ones which can open C# projects).
I think you're best bet is to simply create a list of Visual Studio versions that you care about in priority order. Then enumerate them in your process checking for the first one that is available and launching that process.
The most reliable way to find the installed location of Visual Studio is to examine the InstallDir key inside of
32 Bit: HKLM:\Software\Microsoft\VisualStudio{VersionNumber}
64 Bit: HKLM:\Softawre\Wow6432Node\Microsoft\VisualStudio{VersionNumber}
(Formerly: Help! Sourcesafe hijacks Perforce bindings in visual studio 2005)
Hi,
I'm currently having a problem with a visual studio solution. We're using perforce as our source control provider through the binding mechanism in visual studio.
My problem is that every time I open the solution sourcesafe will hijack the bindings and show me lots of errors about not being able to find the sourcesafe database.
This problem is easily corrected by:
Unbinding the solution and all projects.
Go to options and change source control provider from sourcesafe to perforce.
Rebinding the solution and all projects.
But! I don't want to do this every time i open the solution.
Does anyone her know what's going on here? I preferrably want to fix this without removing the sourcesafe plugin altogether.
Update:
I have removed some registry entries to keep VS from discovering the sourcesafe plugin. This works since sourcesafe no longer can be found in the list of providers in the options. The funny thing is that it still won't use perforce. When I open the solution I still get the errors and the provider is set to "none" in the options dialog.
It seems that this is not a sourcesafe problem, but a visual studio problem. Does anyone know where visual studio stores its bindings on a project and solution level? I have checked the .scc and .vssscc files and found no mention of perforce. (Other than project name: "perforce project")
regards,
Yngve
Visual Studio supports only 1 Source Control at once, so you need to switch providers through options BEFORE you open the solution. (open VS, switch providers, open solution).
After a lot of digging, in the registry as well. I found a little list of source control providers under the following key:
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\SourceControl\EngineNames]
"0"="Sourcesafe"
"1"="Perforce"
After changing the order to:
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\SourceControl\EngineNames]
"0"="Perforce"
"1"="Sourcesafe"
it correctly associates the projects with perforce. Why, you ask? I have no idea whatsoever.
Whether or not this "fix" will mess with any bindings to sourcesafe remains to be seen though.