In MS Visual Studio 2003, I have several related projects and solutions inherited from other developers.
Some binary files (with extensions including ncb, opt, idb, pdb, and pch) reference absolute file-system paths that don't exist on my PC but did on the previous developers' PCs.
One or more of the projects seem to depend on these paths, because the paths appear in the "Resolve Ambiguity" dialog-box when I try "Go To Definition" in source files in some projects.
I have checked the properties of all the solutions and projects in Visual Studio and can't find any reference to these paths. How can I change or remove them without directly editing the binary files?
Edit:
I've used a third-party text-editor to search all file types in the whole directory tree for these solutions and projects.
I've searched for the bad paths containing both single and double-backslashes.
Also, one of the paths contains a username, so I've searched for just the username without the rest of the path.
All of the bad paths are referenced only in binary files. They don't appear in any source-code, solution (.sln) or project (.vcproj) files.
Solved...
According to other resources, the binary files can be deleted.
I deleted those files and rebuilt the solution, which caused Visual Studio to recreate the binary files, and now there's no reference to the nonexistent paths.
I had thought the path references might be the cause of a problem I had running a test application for the solution, but that turned out to be unrelated - the test app was loading an old DLL from C:\Windows\SysWOW64 when I expected it to be using my latest built version.
Related
I'm working ona project containing thousands of solutions (.sln) and tens of thousands of .cs/.cpp/etc files.
How can i find which solution(s) a source file is a part of?
Source files aren't part of a solution. They are part of a project, which in turn is part of a solution. The source file itself has no notion of being part of the project though. The project has a reference to the file but not the other way around. One source file can be part of multiple projects, which might be part of different solutions.
What you could do is parse the SLN and VBPROJ/CSPROJ/whatever files to see which ones refer to a particular source file. Those files are just text and contain various information about the solution or project, including what projects are part of a solution and what files are part of a project. You could recursively parse the files in folder to build up an entire tree representing the files in the projects in the solutions.
Note that most files are going to be referred to by relative paths in the project file.
Start with Visual Commander and then you can programmatically access your solution "DOM-style" using Visual Studio's Automation and Extensibility for Visual Studio API. Write a VS command in a .NET language that traverses a solution into its projects and then into the project items, dumping all files found (project items) into a log file, database, web service, what have you.
See e.g., this article HOWTO: Navigate the files of a solution from a Visual Studio .NET macro or add-in on how to navigate Visual Studio's DTE.
I know SO frowns on answers containing just links and not true help, but the documentation for EnvDTE in its various flavors is extensive and any code sample to demonstrate how to use it would be quite large. So I'm just giving you this strong hint: Look at the Visual Studio extensibility model, and hook into it easily via Visual Commander which does all the hard work of wrapping your code in a Visual Studio extension. From there you can use any reasonable technique (MSBuild, PowerShell, batch files) to load each solution into VS and run your new command.
This actually answers the question: For all source files used by any of my thousands of solutions, which solutions use them. But I see that you (#Sabz), below in a comment, give a reasonable way to answer the question for one source file at a time, which is more precisely what you asked.
N.B.: I have not (yet) used Visual Commander so I'm just assuming it works as advertised.
I'm storing some artifacts, and I have .lib files and .dll files in separate subdirectories. Are .pdb files searched for based on the startup directory (like .dll files) or are they searched for based on the link directory (i.e. the location of the corresponding .lib)?
I know I can specify the search paths, but I'm interested in the default Visual Studio 2010 behavior.
Edit: Doh, this has been indirectly asked and answered before, and I didn't find the question on my initial search.
While remote debugging how are the pdb located (VS 2008)
As you know, when the debugger starts a session, it begins to search for the location where PDB are located. The following article describes the mechanism and the search order of the process.
I try to get familiar with version control systems (mercurial to be exact) - nearly everything works as it should, but I have trouble with Solution files of the Microsoft Visual Studio 2010 which contain several projects.
Things I add to the ignore list: Bin/debug/Object folders (of course), the .suo file and .csproj files.
Ignoring .csproj files does not seem to be the best idea since other users of my mercurial repository have problems when opening the vs solution: the included projects are "defect".
But including the csproj. files on the other hand also causes trouble as you can read on several pages, or am I wrong here?
What can I do? Thank you
Ignoring .suo files is a good idea since they contain specific user options.
Csproj files represent files defining projects in your solution. So solution defines a number of csproj files, and csproj files define what files/folders are contained withing the projects themselves. You absolutely have to add them to the repository.
get from https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473
The standard setup for .NET solutions is that each assembly gets its
own bin directory to which it is copied along with the assemblies of
all its dependencies. If your solution contains an .EXE file and, say,
40 different assemblies. Does it really make sense to copy the
dependencies of each assembly to each separate build directory? The
target directory of the EXE should be enough. Another way to
accomplish roughly the same would be to give the assemblies common
output directories. That also avoids the copying. Some earlier
versions of Visual Studio did not support this well, so be careful. I
have, however, been using this approach with VS2008 for quite a while
without noticing any problems.
question - how to disable creating "bin" etc for all child projects? Thanks
Edit - there is a more comprehensive answer at Optimizing Visual Studio solution build - where to put DLL files?.
Create top level /bin/ folders above all your child projects. Then for each project, right click and go to properties. On the build tab, you can amend the "Output path" to point to your new top level bin with a relative path (e.g. ../bin/Debug or ../bin/Release). You should do this for each build configuration (e.g. Debug and Release).
This should result in each assembly being copied just once to the same location.
Note I've checked this procedure in VS2008 but I suspect it is similar in 2010.
If I have a visual studio solution with a multiple projects, from the projects how do I figure out which one will have all the dlls once the solution is built?
The reason is I need to copy those dll's for my custom written build app. I know in the Visual studio GUI, if I right click on the solution and go to Project Build Order, the lowest level item will be the project which will have the complete list of built dll's and referenced dll's. So is there any logic I can use to work this out through code?
You could write some code to read the solution / project files (the formats are not hard) and work out the dependency tree yourself.
However, a better approach is to change all the projects to output to a common \bin directory to start with by altering the build properties in Visual Studio. This avoids you having numerous copies of binaries in various individual project bin directories and makes life easier when it grows to a size where you need to split into multiple solutions.
A directory structure something like the following is often useful:
\bin (Common output directory for all projects)
\src (I usually keep the solution file in \src)
\ProjectA
\ProjectB
\lib (Common libraries, e.g. nunit or log4net etc)