I work in a team on a Visual C++ project. Following advice we got we're tracking the project's .sln file with our SCM. It turns out that each time I pull from my partner (yes, we use git) and open the solution in VS, the .sln file is updated. The part being updated is the long id that appears several times (in this case ending with 7C44) in the following segment:
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Debug|Win32.ActiveCfg = Debug|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Debug|Win32.Build.0 = Debug|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.DebugStaticCRT|Win32.ActiveCfg = DebugStaticCRT|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.DebugStaticCRT|Win32.Build.0 = DebugStaticCRT|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Release|Win32.ActiveCfg = Release|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Release|Win32.Build.0 = Release|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.ReleaseStaticCRT|Win32.ActiveCfg = ReleaseStaticCRT|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.ReleaseStaticCRT|Win32.Build.0 = ReleaseStaticCRT|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Template|Win32.ActiveCfg = Template|Win32
{828CB89E-F092-3B7A-2F8C-62E146587C44}.Template|Win32.Build.0 = Template|Win32
What does this number mean? How can we make it stop changing between us?
I had a difficult time finding this particular post when searching for the answer, so I just wanted to add some key words and explanation to make it easier to find. Thanks to the fantastic answers by Daniel and tgb I was able to resolve this issue and my team and I no longer have conflicting solution files after opening Visual Studio 2010 (I would vote their answers up, but I just joined today and do not yet have enough reputation points to vote answers up...).
So, to ask the question in a few more ways:
Why does Visual Studio change .sln files when opening a solution? Why do .sln files have local modifications? or What causes merge conflicts in Visual Studio Solution files?
Answer: Most likely a different or missing ProjectGuid attribute in the .vcxproj Project file will cause local modifications. This could be due to upgrading projects from previous versions of Visual Studio or just from manually copying a project file and editing parts of it.
The fix is to add the line:
<ProjectGuid>{###}</ProjectGuid>
(with the appropriate ID from the solution file in place of ###) to the .vcxproj file in the 'PropertyGroup Label="Globals"' node, for example:
<PropertyGroup Label="Globals">
<ProjectGuid>{FD0675C0-EC06-E665-4001-12DEE6694605}</ProjectGuid>
<RootNamespace>MyProject</RootNamespace>
</PropertyGroup>
Otherwise Visual Studio will just assign a new random ProjectGuid to each project and update the .sln file. The 'ProjectGuid' can easily be found for a given project in the .sln file:
Project("{<Filter#>}") = "MyProjName", "src\to\Proj.vcxproj", "{<ProjectGuid>}"
That is a GUID which Visual Studio uses to refer to the individual projects. You will find the same GUID at the top of the .sln file, where the projects are defined/imported.
Visual Studio reads the GUID from the corresponding .csproj/.vbproj file. There you should find a ProjectGuid property near the top with the corresponding GUID. If you and your partner have a different GUID defined there, the .sln will also update.
I've had the same problem.
I finally noticed it came from a vcxproj file which didn't define its GUID.
I manually added this GUID in my vcxproj file :
<PropertyGroup Label="Globals">
<ProjectGuid>{D3303AD3-B7E5-48F8-919C-18202ABAEF00}</ProjectGuid>
<RootNamespace>MyProject</RootNamespace>
<ProjectName>MyProject</ProjectName>
<Keyword>MFCProj</Keyword>
</PropertyGroup>
Related
So I just made some c++ application, using NotificationIcon sample from Microsoft as a reference, and thus I'm stuck with the NotificationIcon.exe output file. The name is really lame and I'd like to change it. I've tried renaming the exe, renaming the solution, the project - whatever else - and my programm just exited with code 0x00 after building. What else should I try?
I tried to do the same thing, but there were a few steps I had to follow in VS2019 just to get set up. If you are not in a similar state, the rest of the answer might not apply.
Downloading the sample: I had to install the Windows 7 SDK, as the download page didn't seem to exist anymore. I'm not sure if you found it elsewhere, in which case you might be starting from different sources.
Converting the .vcproj file to .vcxproj. Visual Studio no longer supports .vcproj, and opening the solution triggered this conversion automatically.
Now, once I have a .vcxproj file, there are two routes to setting the name of the exe:
Right-click the project in VS, click Properties, and find the Target Name field. This defaults to $(ProjectName) so I would have expected that renaming the .vcxproj would have renamed the .exe file.
Edit the .vcxproj file directly, adding <TargetName>Foo</TargetName> into the section that starts with <PropertyGroup Label="Globals">
I'm using Visual Studio 2015 with Xamarin.Android. My solution compiles and links fine, with no warnings or errors. It runs correctly on my target device.
However, Intellisense can't find the autogenerated Resource.designer.cs file (which provides all the resource ID constants for things like page design elements from .axml files, string resources, assets and so on).
If I have code like: var button = FindView(Resource.Id.some_button);, then in the edit window the "Resource" part will have a red underline, and if I mouse over it, I see: "The name 'Resource' does not exist in the current context."
In the Output window, if I change the dropdown to show output from Intellisense, I see a line like:
[Failure] Could not find file 'C:\Users\dghenke\Downloads\Widget\Widget\Widget.Android\obj\Debug\designtime\Resource.Designer.cs'.
That path exists up to the Debug\ folder, but there is no designtime\ folder underneath.
Things I have tried:
Closing and re-opening Visual Studio.
"Clean Solution" followed by "Build Solution".
Completely removing my source tree then fetching a fresh copy from source control.
Checking my .csproj file to make sure that <MonoAndroidResourcePrefix>Resources</MonoAndroidResourcePrefix>
<AndroidResgenClass>Resource</AndroidResgenClass>
<AndroidResgenFile>Resources\Resource.designer.cs</AndroidResgenFile>
is in the first <PropertyGroup> element.
Removing the Resource.designer.cs file from the project and re-adding it.
Things I have not tried (and would prefer to keep it that way): Creating a whole new solution from scratch then manually re-adding all my source files from the original.
Versions:
Visual Studio Professional 2015 14.0.25431.01 Update 3
Xamarin 4.8.0.756
Xamarin.Android 8.1.0.13
What finally worked for me was addding:
<AndroidUseManagedDesignTimeResourceGenerator>False</AndroidUseManagedDesignTimeResourceGenerator>
to the first PropertyGroup in my .csproj file.
I meet a strange problem when I use visual studio 2010. I have many projects in my solutions. When I add a folder in my solution(in visual studio, not windows explorer), it automatically changes some projects in the solution, i.e, the .csproj file. Basically, it changes the name of some projects it references. For example,
<ProjectReference Include="..\..\..\Common\Common.csproj">
<Project>{EXXXXX-XXXXX-XXX-XXXX-XXXXXXXXX}</Project>
<Name>Common</Name>
</ProjectREference>
is changed to
<ProjectReference Include="..\..\..\Common\Common.csproj">
<Project>{EXXXXX-XXXXX-XXX-XXXX-XXXXXXXXX}</Project>
<Name>Common %28Common\Common%29</Name>
</ProjectREference>
That is, it adds something to the name. but it only changes one or two project name it references, not all the projects it references. BTW, I only added a folder to the root of the solution. It's totally irrelevant to other projects in the solution.
Although this is not a big problem, it doesn't affect compiling and execution of the program, it's quite annoying. Anyone knows what causes this problem?
Visual Studio drives me crazy and I am suspecting I am doing something wrong.
This is what I do: I installed Visual Studio (Pro '08) a long time ago, I installed the Windows SDK (Win 7 x64), someone emails me a project, it fails to build.
Invariably, it can not find windows.h. While it is easy enough to include C:\Program Files\Microsoft SDKs\Windows\v7.0\Include in the project settings of every single project, I feel that this may not be the proper way to do it. Is there a way to somehow make Visual Studio globally aware of these files?
I also tried to include the above directory in the path variable but that didn't change anything.
Also, it will randomly find windows.h but not winresrc.h in the same directory.
Edit:
It was a problem with my machine. Somehow, Visual Studio thought that my Windows SDK was in the wrong place. See accepted answer and comments for the fix.
#RichieHindle solution is now deprecated as of Visual Studio 2012. As the VS studio prompt now states:
VC++ Directories are now available as a user property sheet that is added by default to all projects.
To set an include path you now must right-click a project and go to:
Properties/VC++ Directories/General/Include Directories
Screenshot:
This answer only applies to ancient versions of Visual Studio - see the more recent answers for modern versions.
You can set Visual Studio's global include path here:
Tools / Options / Projects and Solutions / VC++ Directories / Include files
To resume the working solutions in VisualStudio 2013 and 2015 too:
Add an include-path to the current project only
In Solution Explorer (a palette-window of the VisualStudio-mainwindow), open the shortcut menu for the project and choose Properties, and then in the left pane of the Property Pages dialog box, expand Configuration Properties and select VC++ Directories.
Additional include- or lib-paths are specifyable there.
Its the what Stackunderflow and user1741137 say in the answers above.
Its the what Microsoft explains in MSDN too.
Add an include-path to every new project automatically
Its the question, what Jay Elston is asking in a comment above and what is a very obvious and burning question in my eyes, what seems to be nonanswered here yet.
There exist regular ways to do it in VisualStudio (see CurlyBrace.com), what in my experience are not working properly. In the sense, that it works only once, and thereafter, it is no more expandable and nomore removable.
The approach of Steve Wilkinson in another close related thread of StackOverflow, editing the Microsoft-Factory-XML-file in the ‘program files’ - directory is probably a risky hack, as it isnt expected by Microsoft to meet there something foreign. The effect is potentally unpredictable. Well, I like rather to judge it risky not much, but anyway the best way to make VisualStudio work incomprehensible at least for someone else.
The what is working fine compared to, is the editing the corresponding User-XML-file:
C:\Users\UserName\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props
or/and
C:\Users\UserName\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props
For example:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets">
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<IncludePath>C:\any-name\include;$(IncludePath)</IncludePath>
<LibraryPath>C:\any-name\lib;$(LibraryPath)</LibraryPath>
</PropertyGroup>
<ItemDefinitionGroup />
<ItemGroup />
</Project>
Where the directory ‘C:\any-name\include’ will get prepended to the present include-path and the directory ‘C:\any-name\lib’ to the library-path. Here, we can edit it ago in an extending and removing sense and remove it all, removing thewhole content of the tag .
Its the what makes VisualStudio itself, doing it in the regular way what CurlyBrace describes. As said, it isnt editable in the CurlyBrace-way thereafter nomore, but in the XML-editing-way it is.
For more insight, see Brian Tyler#MSDN-Blog 2009, what is admittedly not very fresh, but always the what Microsoft is linking to.
If you are only trying to change the include paths for a project and not for all solutions
then in Visual Studio 2008 do this:
Right-click on the name of the project in the Solution Navigator. From the popup menu select Properties. In the property pages dialog select Configuration Properties->C/C++/General. Click in the text box next to the "Additional Include Files" label and browse for the appropriate directory. Select OK.
What annoys me is that some of the answers to the original question asked do not apply to the version of Visual Studio that was mentioned.
To use Windows SDK successfully you need not only make include files available to your projects but also library files and executables (tools).
To set all these directories you should use WinSDK Configuration Tool.
This answer will be useful for those who use a non-standard IDE (i.e. Qt Creator).
There are at least two non-intrusive ways to pass additional include paths to Visual Studio's cl.exe via environment variables:
Set INCLUDE environment variable to ;-separated list of all include paths. It overrides all includes, inclusive standard library ones. Not recommended.
Set CL environment variable to the following value: /I C:\Lib\VulkanMemoryAllocator\src /I C:\Lib\gli /I C:\Lib\gli\external, where each argument of /I key is additional include path.
I successfully use the last one.
You need to make sure and have the following:
#include <windows.h>
and not this:
#include "windows.h"
If that's not the problem, then check RichieHindle's response.
We're using Jon Skeet's proto-csharp-port, and I'm running into some difficulties when mixing it with ReSharper in Visual Studio 2010.
We generate the .cs files via a custom MSBuild target, hooked up as follows:
<Target Name="BeforeBuild" DependsOnTargets="CompileProtos" />
The CompileProtos target runs ProtoGen and then adds the generated .cs files to the #(Compile) item group, by using CreateItem. This looks in a defined directory and compiles every .proto file it finds, so they're not listed in the project.
Where it falls down is that ReSharper doesn't recognise the content of the .cs files (because they're not in the project and might not exist yet), so I can't get the solution analysis light to go green.
If I add the .cs files to the project, then I get a build failure, because the .cs file has been added to the Compile item group twice.
I know that Marc's protobuf-net has Visual Studio 2008 goodness in it, and I'm looking for something similar, but for Jon's protobuf-csharp-port and for Visual Studio 2010.
Ideally, I'd like to be able to add the .proto files to the project, have them built correctly, and have Visual Studio and ReSharper know about the generated .cs files, so that IntelliSense and solution analysis work properly.
I'm guessing that something like how .xsd files can implicitly generate .cs files would do the trick.
I've attempted to get this working by implementing a custom tool for code generation, but I've run into a seemingly insurmountable hurdle:
protoc takes a directory full of .proto files and generates a .protobin file. This is then fed to ProtoGen which spits out a .cs file for each protocol definition. Unfortunately, it appears that the .protobin file needs to contain all of the definitions, otherwise you get Error: Unable to resolve all dependencies.
Since the custom tool model in Visual Studio assumes a single input file and a single output file (i.e. foo.proto -> foo.cs), it doesn't look like this can be made to work.
At least, not without finding some way to include all of foo.proto's imported .proto files in foo.protobin, anyway.
I solved it by removing the CreateItem from the CompileProtos target, and by defining it as a proper ItemGroup:
<ItemGroup>
<Protocols Include="$(ProtocolsPath)\*.proto"/>
</ItemGroup>
<ItemGroup>
<Compile Include="#(Protocols -> '%(Filename).cs')"/>
</ItemGroup>
This means that Visual Studio (and ReSharper) pick up the .cs files correctly, once they've been built, and ReSharper's full solution analysis stops complaining.
Unfortunately, Visual Studio has a habit of expanding the ItemGroup into individual Compile entries, but I can check for that before checking anything in.