I am currently working on a VS Extension that stores solution-specific metadata to a SQLite (.db) file.
Can (and should) I be storing this in the new (as of VS2015) .vs folder that sits alongside the .sln file? Or is this storage location meant for Microsoft'y, internal visual studio'y things only?
Is there a special API or anything that needs to be utilized or can I just dump a load of files and folders in there?
I've searched and not found any real info about extension development and the utilization of that folder.
Thanks!
Should my VS Extension use the “.vs” folder?
Personally, you can use .vs folder but not recommend.
Indeed, there is no specific documentation for the folder .vs. AFAIK, this .vs folder was not invented by the Visual Studio developer team. It is there because someone asked for it. and many other Visual Studio users on the Visual Studio UserVoice page. The IDE team looked at it, thought it through, accepted it and implemented it. This should be the reason why there is no specific documentation for this folder.
Usually, .vs folder is required by Visual Studio to store opened documents, breakpoints, and other information about state of your solution. So, it looks like a normal folder without any other special restrictions, you could use it.
But this .vs will sometimes be deleted and regenerated to solve some issue, and the folder is not intended for source control, source control ignore this .vs folder by default. So, it should not the best solution to use .vs folder.
Related
When I installed Visual Studio, it also placed hundreds of files on my external hard drive. And now the folder structure is full of "junk" that I don't want.
Is it safe to delete these files? Will deleting these files affect my Visual Studio installation (which is on a different disk) at all? Why does VS do this anyway? Why does it place all this crap on a drive I never even gave it permission to put it on in the first place?
You can safely delete any of those files, since, quoting Microsoft KB,
These temporary files are erroneously generated by the installer into the root directory of one of your drives, instead of the temp directory
Those are temporary files indeed and they, still quoting Microsoft,
are generated on the root directory of a drive that has the largest available space in the system
Check Microsoft knowledgebase pages like this for more detail.
What about archiving those files, opening visual studio and check it is still working?
If it doesn't just put the files back where they were...
You should be safe deleting those files. Someone already asked this question. :D
Visual Studio 9.0 Beta Program files in C:\
hope I was helpfull
Jasper.
Cause
These temporary files are erroneously generated by the installer into the root directory of one of your drives, instead of the temp directory.
Resolution
These files are unnecessary and can be safely deleted from the system. The functioning of the runtime library will not be affected by this.
Its a known bug and is fixed in VS2008 SP1.
Ref: https://support.microsoft.com/en-us/kb/950683
How do I create a Visual Studio Project for Development on my Local PC that links to Existing files and folders on a Server?
My employer has a large website. Most of that girth (close to 100 GB) is contributed to Portable and Image document (i.e. PDF and JPEG) files, but there are also numerous web files (.html, .aspx, .php, etc).
We have the following folders:
a WORKING folder that contains everything that is "Live" on our web server.
a BETA folder that contains newest technologies that are being tested and tried.
a DEVELOPMENT folder that contains numerous copies of projects that are being worked on by the different developers.
Developers are allowed to use whatever tools they prefer, so we have people who develop using Notepad++, Dreamweaver, Komodo, Zend Studio, and (now) Visual Studio.
It is NOT OK for me to create Visual Studio Projects for myself on the network servers. Other developers using other tools are not creating solution files or \bin and \obj folders on the servers, and I certainly should not be either.
So, to work on a file in Visual Studio, I use Windows Explorer to browse to the location, then I open it in the IDE.
However, this causes me to lose a lot of the power of Visual Studio - particularly if other classes used in this file, because I would have no access to the Intellisense for that class and I cannot simply Right-Click and go to definition.
Also, since each development environment is so large, I can not copy them to my laptop with its high tech 125 GB Solid State Drive (should be interesting to read that in a couple of years).
What I would like to do is create the Visual Studio Projects on my local drive, and then have them reference the files and folders on our network.
I've looked and found these similar questions, but my goal is slightly different:
Working efficiently on remote projects in Visual Studio
How do I add an existing directory tree to a project in Visual Studio?
How to "Add Existing Item" an entire directory structure in Visual Studio?
These are all great topics, but none of them show a way to create a local project that uses remote files.
It would seem that developers in large company teams would have already developed a way to do this, and that I just do not know what it is called.
I have found a way to do this!
For a long time, I was working with 2 sets of folders. One for our repository and one for Visual Studio.
I'd make changes in Visual Studio, then copy those working files over to the repository folder.
That was time consuming! Very.
Here is how I found to fix it: Open the Visual Studio Project file (*.csproj, *.vbproj, or *.phpproj) in NOTEPAD with Visual Studio closed.
Locate the <ItemGroup> tab, and change every path to be from the one shown to one that uses a relative path to get to the actual files.
Notepad's Replace... CTRL+H will save you hours here!
It makes a funky looking project environment, but it works!
If this helps anyone else or if it were even something you didn't know you could do to manipulate Visual Studio, kindly vote it up.
If I have a project called 'testing' in project A.
How can I share that folder 'testing' for project B in visual studio 2010?
The reason I would like to achieve about this is because when I change something in the folder testing of project A, I dont want to change the same things in project B.
Thanks in advance.
Maybe too late for the person who asked the question, but this is for people with similar problems. You can share folder contents with an extention 'Project Linker':
This builds upon the concept of linked files where you refer to the same file from two projects. This extention handles the management of that for an entire project. If you add a file to the project, it will be added too to the other project as a linked file. Same for deletes...
Attention: you need to have both projects in the same solution for this to work of coarse...
Extention VS2015
I used it in VS2010 and it's also availible for later versions.
You can't share folders in Visual Studio - they are logical constructs that are part of a solution or project.
The closest you can get is to add folders to the projects you need to share on and add all the files that you want to share as links. You will still need to manually synchronize all adds/deletes of files, but updates will come across all projects.
To make things easier, you may want to write a Visual Studio macro that synchronizes these folders for you (you can bind these to keyboard shortcuts and/or menu items).
If you put your solution (*.sln) files in the same directory they can share files in sub directories.
I'm trying to view history in Visual Studio 2010 for all files included in a given Solution file via the Solution Explorer View. I use TFS 2010 for source control, and I'm aware that I can get history for a folder recursively in Source Control Explorer. My issue is that we have multiple projects in a root directory, all of which are included in a variety of solution files in that same directory (each solution file represents a deploy-able component, including some "shared code" between them). I just want to view history on all of the files included in a given solution file, and not everything in this root directory. When I right click on a solution or project in Solution Explorer and "View History", I just get history for that solution file or project file, nothing more.
Alas, this cannot be done with TFS as it is.
TFS Source control does not know if a file is a solution file or a text document. It just stores it for you. There is no parsing at all. I can (and do) store Delphi project files in TFS. There is no way for TFS to be able to understand and be smart about every file type that exists.
It would be nice if Solution explorer did this for you (as it is specific to your project). But it does not.
You could create a custom plugin to TFS and Visual Studio to do what you are asking, but it would probably take longer than just manually checking the history of all the files in your solution.
This might help, it's an add-in extension
VS 2010 and VS 2012
When I try to open my .sln file, Visual Studio quits on me. I can open it by opening up TFS, getting a specific version, choosing the latest version, forcing an overrwrite, opening up the .sln file, and then ignoring an 'incompatible doc message".
However, I would like to know what's wrong and how it can be fixed, in case some day I can't do this.
How can this be fixed?
I would think this is more likely to be the .suo (which is a hidden file). These are know to corrupt (and this has been true since at least VC++ V6). Deleting it will clear all sorts of odd/erroneous behaviour in VS.
(The .suo holds local settings: which files are open and layout, breakpoints, bookmarks, ... only: nothing that really matters to the solution or projects.)
For Visual Studio 2015 and 2017: rather than being in the same location as the solution (.sln) file, it is now held in a, hidden, folder called .vs in the folder containing the solution file.
In Visual Studio 2022, the .suo is in \.vs\MySolution\v17\
Have you tried creating a new sln and importing all the projs? if it doesn't solve the corruption, it may point to a project with a problem.
Get copies of both versions of the file and use your favorite dif tool to see what's changed. sln files are xml (i.e. human readable), so it isn't too hard to figure out what happened.
Difficult to tell. A sln file is quite simple structured, if you open it with a text editor,
check is everything looks all right to you.
Seems to me that the sln file could be in a conflicted state.