Where does the indication of unavailable or available (loaded) projects / websites is saved?
I have a solution which has some unloaded projects while only the website is loaded
Of course I can right click and reload it but still, I want to now where this [unavailable or available] info is saved?
I've been looking in the sln, there is no difference (beyond compare) between loaded one and unloaded one.
Also in Websites.xml, there is no such difference
The suo file stands for "solution user object" (it's a guess).
It's a per-user container of solution settings.
You can safely delete it, but you will lose some other non important things, like breakpoints, and so on.
In most VCS, this file is in the standard exclusion list, as it should remain specific for each user. This is the evidence you can safely delete it.
I believe the information regarding loaded and unavailable projects in a solution is stored in the .suo file. As mentioned previously, this is a user-specific, binary settings file auto-generated and maintained by Visual Studio.
It's worth pointing out that some projects won't load if the machine doesn't have the relevant software installed (e.g. an MVC web application project won't load on a machine that does not have it installed; similarly for WIX projects).
If you have intentionally unloaded projects to improve the overall load time of your solution, then you should know that Visual Studio 2012 now supports asynchronous loading of projects.
You might also have a look at spinning some projects out into other solutions, grouping by major system features (be wary of breaking project dependencies.)
Related
We currently have a number of C++-based products that build under Visual Studio, and are maintained under MKS.
In order for our automated build system (which comprises a number of custom scripts) to increase the version number of the software it must first determine if any of the files within the project have been modified since the previous build.
The current method for performing this check is to check for changes to files in the directory tree below that containing the Visual Studio solution. This works well enough, but it completely misses those files that reside in other, e.g. shared/common, directories and have been added to the solution as existing items.
I know that this must be a common issue, so I'm wondering what are the usual techniques for managing this sort of thing. I realise that one option is for there to be no common source files, and instead have shared libraries, but that is quite a long way from the current reality. What I'm hoping to find out is that for A.N.Other source control system there are plugins that 'support' visual studio solution/project files, and will check for changes in the files included therein. I think if I had that ability then the problem will go away.
So I am working on a solution with a lot of projects with multiple developers using SVN. There are some projects that are specific for me that I want loaded but for others they might not be relevant.
So my question is, where does Visual Studio store information about a project begin loaded and what is the proper way to commit project/solution settings with out ruining it for others?
An example could be that I just added a new project to the solution and I want to commit these changes, but I don't want to commit whether or not a project is loaded/reloaded (Since other developers have to reload them again).
EDIT: I found the answer here When I unload projects in visual studio, where does VS save this setting?
When you add projects to a solution, they will get loaded when the solution opens.
If using source control, if such a solution is updated and contains new projects, they will get loaded.
One way of dealing with this is to create multiple solutions - solutions that only have relevant projects. These solutions can be part of source control, but don't have to, though if you don't add them to source control you risk having projects in source control that only you have a solution reference to.
I found the following information about the Microsoft Visual Studio "extra" files:
What is the purpose of the vshost.exe file?
My question is, is there a way that I can NOT have the .pdb, .manifest and vshost.exe files from being made? Or are they absolutely necessary?
I just noticed that after debugging it, it's still showing up as a running process in my machine which worries me since I already closed it.
Switch to the Release configuration. Then Project + Properties, Debug tab, untick the "Enable the Visual Studio hosting process" option. Build + Clean, you can delete anything that's left and it won't come back. That this option is turned on by default for the Release build is, arguably, a bit of a flaw but defensible.
The hosting process is a custom hosted version of the CLR. Exactly what it does is not well documented but it is related to configuring the security settings of the primary AppDomain. I've never heard anybody complain about battling CAS problems without it, but then it is unusual to turn it off and your app almost always runs in full trust when debugging from the IDE. It would matter if you build to a network share on early versions of .NET. The only thing that's obvious from disabling it is that anything you write with Console.Write in a gui style app will no longer appear in the Output window. It has nothing to do with speed as claimed in the highly upvoted answer in the link, the core framework DLLs are already resident in RAM since VS and MSBuild uses them.
Best thing to do is just not worry about it too much. A Setup and Deployment project will ignore it.
Regarding vshost files, at least in VS2010:
They are not generated on build, but on selection of build configuration (it will be generated in release when we select release for the first time) and on setting "Enable the Visual Studio hosting process" to true. (As configuration debug and this option set to true are defaults, vshost.exe will be created in bin/debug on opening VS with target project by default.)
They are not cleaned on rebuilding or cleaning the project, but only manually when "Enable the Visual Studio hosting process" is false if VS with that project is open. (And it won't be generated anymore when opening this project.)
If this flag option is true and VS with target project is opened, this file cannot be deleted as being used. Once when it is unchecked, vshost.exe can be immediately deleted.
Summary: Generating and removing these files is not related to build process.
Also, I may add that option "Enable the Visual Studio hosting process" in referenced projects which are class libraries is not considered. This option is only considered for target project which generates executable file.
We are looking for a Version Control System to change our current Source Safe one. We are using it along with Visual Studio. We've failed so far - and the main reason for it is that all the alternatives we see doesn't support one or more features of VSS, especially one that we use widely - file share! What's up with that?
Alternatives like Source Gear claim to support them, but I gotta tell you that they do that very poorly. Not to mention that they are way slower than Source Safe, and have even more bugs.
What alternatives we do have to source version systems that do support file share? Or is there a reason to not use features like this? Please share your experience and support your comments.
EDIT:
By Share File I mean that I can checkout a file from any project that is sharing it, do some changes and then all get the latest version. It is very useful when working with C++ projects, or even C# Web Projects. I want to be able to share a file without the need to make another library for that.
From MSDN:
Sharing Files or Projects
Visual SourceSafe has a Share command that allows sharing of files or projects. For use of the command, see How to: Share an Item.
When you request file sharing, Visual SourceSafe creates a shared link between the versions of the file in the projects that share the file. When you check in the file to one of the projects, your changes are automatically checked in to all the sharing projects. All the projects that share a specific file are listed in the Links tab for the file.
When you share a Visual SourceSafe project, you create a completely new duplicate project under the current project. All the files in the new project are shared with the corresponding file copies in the shared project, and changes in one are reflected in the other during check-ins to the Visual SourceSafe database.
Other tools do have similar concepts, though not always with the same name or exactly the same semantics. Off the top of my head:
Subversion externals
MKS SI (shudder) calls them shared sub-projects
I tend to avoid them because it indicates there are some other issues with my project. If the resources are needed across many projects, I package them as a library and set my other projects to depend upon that artifact (using a dependency management tool such as Maven or Ivy to manage the dependencies)
In Subversion, you can share a whole folder (and its subfolders of course) with the svn:external property.
And since version 1.6 you can also share files.
In Git, those are called "submodules" - not sure if they work for single files though.
This post http://blogs.msdn.com/ericlee/archive/2006/07/20/sharing-files-in-team-foundation-server.aspx shows how you can accomplish the same thing with Visual Studio and TFS.
In StarTeam you can share files across projects.
I apologize if this is not really addressing the original question but depending on your will to "change mindset" for which version control system to use I would strongly suggest moving to a distributed one such as Mercurial or Git. There are plug-ins for Windows Explorer and Visual Studio for both.
As to specific features such as VSS-style file sharing I suggest setting up a Continous Integration environment like TeamCity and configure it appropriately.
It's a steep curve at first but awesome and time-efficient once your staff and servers know what to do.
With Visual Studio (2008), is it possible to load a project (to a solution) that exists on a remote location ?
Basically what I want to do is somehow "host" a VS Project online and then load this project to a solution from a remote location. Is this possible in some way?
This is so that I can keep integrity when loading my Utils Library (used in tons of projects) and I don't want copies of my project in different projects and all having different versions etc...
I know that a possible solution is to have the Utils Library project hosted in SVN and then the folder would sync to it directly, but is there any other way to do this (ie, something more direct) ?
Yes, if you can map a network drive to it, the you can open the files from the location in visual studio.
you can map network drives to ftp servers by entering "ftp://your-ftp-server" in the path box.
Like others have said though, it's not really recommended. VS reads/writes a lot more than just to edit the main project files, it does all kinds of other stuff, so your network traffic be higher than you really want.
Or you could look at dropbox. It comes with a explorer addin that keeps your local PC in sync with the server.
My recommendation would be to use source control like subversion though.
It is possible, but not recommended (you'd be better using some form of source control, be it SVN, or a shared source provider like Codeplex (for open source projects) or TFS Preview (for closed source projects)
Is it not simpler just to have the compiled dll referenced in each solution? The way you are proposing is going to open you to changes to the project for one solution causing problems in a bunch of other solutions, that you might not immediately see.
Better to have a version of the Utils dll referenced in each sub solution and you can then update that dll when necessary, and test at the same time.