I'm comparing two solution files and I find a strange difference between them. They both build properly, and source control seems to work. I'd like to believe that I'm seeing a difference that makes no difference, but I need some help convincing myself.
In
Global
GlobalSection(TeamFoundationVersionControl) = preSolution
one of the solutions has
SccNumberOfProjects = 25
and the other has
SccNumberOfProjects = 26
The solution with the "26" has a section
SccProjectUniqueName25 = SomethingTests\\SomethingTests.csproj
SccProjectName25 = SomethingTests
SccLocalPath25 = SomethingTests
but the solution with "25" ends with "SccProjectUniqueName24".
In both cases, the SomethingTests project exists in the solution when opened by Visual Studio.
Also, I looked with File->Source Control->Change Source Control, and found that in both cases, the project in question is bound to the same server, at the correct location in source control, is Connected, and the Status is "Valid"!
So, if anyone actually knows that the "Scc" section is redundant information, or something to that effect, then please let me know, and please let me know where that's documented.
Related
The project I'm working on uses a .NET Solution file, and multiple C# projects. The IDE is Visual Studio 2012, and Perforce is used for source control. The .sln and .csproj files contain the SCC binding information, for example, for .csproj files:
<SccProjectName>Perforce Project</SccProjectName>
<SccLocalPath>..</SccLocalPath>
<SccAuxPath>
</SccAuxPath>
<SccProvider>MSSCCI:Perforce SCM</SccProvider>
... and the .sln file:
Global
GlobalSection(SourceCodeControl) = preSolution
SccNumberOfProjects = 43
SccLocalPath0 = .
SccProjectUniqueName1 = AnotherProj\\AnotherProj.csproj
SccLocalPath1 = .
SccProjectFilePathRelativizedFromConnection1 = AnotherProj\\
SccProjectUniqueName2 = MyProj\u0020Domain\\MyProj\u0020Domain.csproj
SccLocalPath2 = .
SccProjectFilePathRelativizedFromConnection2 = MyProj\u0020Domain\\
... etc ...
According to Perforce, there's a process for migrating from P4SCC to P4VS:
Migrating from P4SCC to P4VS To migrate your solutions and projects
from P4SCC, the Perforce SCC Plug-in, to P4VS, you must do the
following:
1. Strip the bindings from the solution (.sln) file and all of the project files (csproj, vcxproj, etc.).
2. Remove MSSCCPROJ.SCC and other source-control-specific files.
3. Move all developers to P4VS and have them uninstall the old P4SCC plug-in. For detailed instructions, see
www.perforce.com/perforce/doc.current/user/p4vs_p4scc_migration.txt.
However, due to the testing status of the project, these files may not be modified. Further, some developers prefer to use P4SCC.
Whilst I understand that the official process is that the projects and solution be migrated (from P4SCC) to use P4VS, I do remember reading a comment online (for which I don't have a link) where someone asserted that he was able to use both together without modifying the project files.
Is it possible to do this without having to change the Source Control provider upon each start-up, and click through a series of warning/error messages about mismatched bindings? If so, how?
Sorry, this is not possible. It is possible to have both P4VS and P4SCC installed and used with different projects, but individual projects must be bound to a single source control provider.
I've found that you can put a condition on the SCC bindings that live in the .vcxproj, such as below, meaning that you never have to check out the .vcxproj, only the .sln, which for us never really changes.
So now I can work with P4VS whilst others work with P4SCC without ever being interrupted by annoying dialog boxes (at least after initially removing the source control from the .sln).
In the example, I just set BUILD_USE_P4VS=1 in my environment vars. Anyone using P4SCC does not.
<PropertyGroup Label="Globals" Condition="'$(BUILD_USE_P4VS)'==''">
<SccProjectName>Perforce Project</SccProjectName>
<SccLocalPath>..\..\..\..</SccLocalPath>
<SccProvider>MSSCCI:Perforce SCM</SccProvider>
</PropertyGroup>
I'm working on a large, inherited C++ (really, mostly C) project developed and maintained under Visual Studio 2008. Technically, in Visual Studio terms, it is a "solution" consisting of eight "projects", and therein appears to be the rub.
As I'm sure most of you know, Visual Studio grays out the code that it believes to be #ifdef'd out. What I'm finding, though, is that it doesn't seem to do this correctly for the different projects. To keep matters simple, let's just call them Proj1, Proj2, ... Proj8. When I'm working on the Win32 Debug configuration of Proj5, I'd expect that the macros defined in the C/C++ Preprocessor properties configuration of Proj5 would determine what is grayed (or at least that there would be some straightforward way to make it so). Instead, I seem to be seeing views based on properties of Proj1. That is, if Proj1 defines some preprocessor macros that eliminate part of the code, I'm seeing that part grayed even when I'm working on Proj5. And the macros for Proj5 have no effect at all on what I see.
Yes, I did a complete clean and build (several, actually, and even saved everything off to SVN and started in a new top-level folder), and so I'm pretty sure this is not because of some vestigial files produced by an old build. And I'm pretty sure that in other respects Visual Sourcesafe "understands" the context correctly, because (1) the Build menu contains options related to Proj5, not Proj1; (b) at the bottom of the Project menu is "Proj5 properties..." not "Proj1 properties..."; and (c) there is no question that the #ifdef's are working in the program that is built: there are major feature differences, and they are as I'd expect them to be.
ADDED 27 Sept 2010 I still don't have an answer, so let me try this a different way: Assuming I've already run successful builds (which I have) is there anything other than the preprocessor properties and configuration of the currently selected project (and, as noted below, those of individual files, but that is moot in this case) that should influence what code is grayed?
Please see if these preprocessor directives might be set for the individual files. You can do this by right-clicking on a source file and selecting "Properties" from the context menu. It's somewhat counterintuitive to think that the directives can be set for individual files, not just for projects.
If that doesn't help, your best bet might be to use a text editor to look for the problem preprocessor definitions in each of the project files to try to get a better idea of what might be happening.
VS2010 is supposed to help with this. In VS2008, the no-compile browse cache is done after preprocessing, so it can accommodate only one set of macro definitions.
I don't believe that "Build Clean" or "Rebuild" will delete the .ncb files, since they are not part of the build process at all. I do know that deleting these files by hand fixes all kinds of weird behavior, but I'm afraid that in your case it's not going to be a lasting solution (the .ncb files will still get filled in based on a single configuration.)
Make the project the Startup Project and Remove and Re-add the offending Preprocessor Definition
Details:
I found a process that that fixes my MFC projects when this happens (at least temporarily). First I set the project I am working on as the startup project. Do that by right-clicking the project in the solution explorer and selecting Set as Startup Project. Then I go into the preprocessor definitions for the project and deleting the one that is not triggering and clicking OK. You will see a little progress bar a few seconds later appear in the lower right. Once it finishes, go back into preprocessor definitions for the project and add it back in again and click OK. After the little progress bar finishes again, you should see the correct code active again.
autoexp.dat does not seem to take affect in Visual Studio C++ 2005 debugger.
I am not trying to add any custom rules. Just want commonly used stuff like stl::string, to display in a friendlier manner.
Does anyone know. how I can accomplish this? Is this just question of specifying a path to the autoexp.dat file somewhere. The file is available under the Visual Studio installation directory.
I had a similar problem in 2008, with the debugger showing only the e.g. std::vector _Myfirst,
_Mylast members rather than the vector size and children.
Open Tools/Options/Debugging/General and clear the flag "Show raw structure of objects in variable windows"
(Presumably the suggest
This got me the closest.
http://garrys-brain.blogspot.com/2007/12/stlport-visual-studio-2005-visualisers.html
It would appear you need to make adjustments for types while using ports.
Also you might have to make changes to the display to display exactly what you want.
I think this may have to do with the infamous VirtualStore in Windows Vista/7. I could change this in XP but when I try to update the autoexp.dat file in Win7 it creates a copy in AppData\Local\VirtualStore.... instead. I assume that the studio does read the original file when starting, so my changes are not seen. If anyone knows how to be able to edit the actual file please tell me how!
I've got a solution containing multiple projects. I'm only changing the code in one of them, but every time I hit Ctrl+Shift+B, Visual Studio rebuilds all of the others.
I want it to build the other projects, so this is good. What's not good is that, normally, it would see that there was nothing to do. I have a wonky dependency somewhere, so this isn't working.
Is there a tool or macro (or switch) that'll explore the dependency tree and tell me which files are missing or out-of-date, so that I can get it to stop?
I know that I can solve this specific case, by (e.g.) touching all of the project files.
Unfortunately, I've often seen this situation when a file is configured to produce an output file (e.g. an IDL file is configured to output a typelibrary, but doesn't contain a 'library' block, so it'll never create a TLB).
This wouldn't be resolved by touching all of the project files, so I'm looking for something more general to add to my personal toolbox that'll easily tell me why a file is being rebuilt, whether it be because it's older than a dependency, or because the project is misconfigured to expect an output file that will never be produced.
In Options / Projects and Solutions / Build and Run turn up the MSBuild project build output verbosity to Detailed. It should give you an idea of why it is rebuilding all the projects.
If I understand you right, you might solve this by touching all your project's files. It may be caused by a source-file having a last-modified-time that's in the future.
Edit:
I know that I can solve this specific case, by (e.g.) touching all of the project files, but I'd like to add something to my personal box of tricks that I can use in the future, in the general case.
I'm confused - what's the 'general case' of this problem?
Not that I've found. If you know that a project is not going to change often, you can tell the Configuration Manager not to build it. (Right-click on the Solution, and select Configuration Management)
As far as I know ctrl + shift + b is by default bound to BuildSolution, so that would be why all your projects are being build. i'm not really sure what else you could use except for rightclicking the project and pressing build :)
You might want to check in Tools>Option>Projects and Solutions and check if your option is set to Only Build startup project and dependencies instead of all the solution.
Or instead of using ctrl+shirt+b you should simply press F6 on the project you want to build :)
You can use shift+F6 to build just the current project.
While not directly answering my question: "is there a tool that'll work this out for me?", I found the specific problem by using SysInternals Process Monitor:
The project was configured with /analyze, which requires Visual Studio Team Edition, but the version on this PC is Visual Studio Professional, which doesn't support it. Unfortunately, there appears to be a bug in Visual Studio, where it thinks that the .pchast file should be created, even though it has no way to do so. I've raised this on Connect.
I think I might write a macro for Visual Studio Professional that, if /analyze is turned on, simply creates an empty .pchast file at the end of the build...
I'm trying to build a small VS 2005 solution I've just checked out of source control, and I'm getting this easy to understand error:
...\AssemblyInfo.cs' could not be
opened ('The system cannot find the
file specified. ') (The file is fairly
obviously missing)
Because this file's automatically generated, I've never paid it much heed before, and in VS 2003 (which I still work with day to day - pity me) it never seems to matter if it's missing.
So 2 questions:
1. How can I get VS 2005 to regenerate the file.
2. Could anyone explain to me in a couple of sentences what the assembly info file is all about, why it's generated, why it's a good idea to have an automatically generated file critical to my solution building etc etc.
Thanks - Andrew.
Edit: OK, I've googling some more, and it's probably significant that this is in an Nunit Test Project.
Update: Deleting the reference in solution explorer an Alex suggested did the trick, and the project now builds, but I'm not entirely happy with that as a solution. If the file is so unimportant, why is it generated in the first place? And if the file does perform a vital task, what am I missing out on by just deleting it?
Also, is it even possible to get it back? Either by getting VS to regenerate it, or by manually hacking one up (possibly using another as a template)?
This file contains assembly-wide settings like assembly version, name, etc. It is automatically generated when you change those settings using properties pages of the project. You should have this file in the project with sort of transparent icon (I think it is in resource folder or something like this by default). Locate it in the project tree and delete it. Visual studio will stop looking for it during build.
PS: assuming the path starts with .. and not ... then this file should be located one folder up from the project in the source control. So you can try looking there.