Microsoft Visual Studio uses XML to save its .vcproj project files. So diffing XML project files should be easily.
Unfortunately, if you change any of the project file's properties, Visual Studio insists on randomly shuffling the XML nodes of the project file! This makes textual diffing and merging of project file changes basically impossible. Changing one compiler setting can make my visual diff tool think I've changed 50% of the lines in the file! I've even tried some XML diff tools, but they just show a more structured view of the same mess.
Does anyone have any suggestions for maintaining .vcproj files in source control? Or a way to convince Visual Studio to not rearrange the XML nodes in the .vcproj file?
(I have also investigated using tools like CMake to generate .vcproj files from a more diff-friendly text file, but CMake has its own problems.)
This seems to come up every now and then.
Merging vcproj files - SCM's hell
Perhaps it is a problem ripe for a plug-in or other normalizing tool.
It would be a great side-business, until MS decides to fix it. Then you're out of luck - unless of course they offer to buy your IP.
Anyone want to start an open source project, or commercial product? I'm game.
I might have a go at a stand-alone normalizing tool, then see if I can turn it into a plugin.
We are seeing this here at work now, with project files where the configurations are reordered on several peoples computers, and it is very frustrating...
*Note: We all use VS 2008 Pro, not Team
At first it looks like they are randomly reordered, but there is in fact a pattern and it is not random at all.
For one group the configurations are ordered by Platform, then by Config:
Debug|Win32
Debug|x64
Release|Win32
Release|x64
Debug DX11|Win32
Debug DX11|x64
Release DX11|Win32
Release DX11|x64
...
For the other group the configurations are ordered by Config, then by Platform:
Debug|Win32
Release|Win32
Debug DX11|Win32
Release DX11|Win32
Debug|x64
Release|x64
Debug DX11|x64
Release DX11|x64
...
Looking through perforce history, this is consistent with multiple projects submitted by the same sets of people, and there is about a 50/50 split, so it is not just happening for one person.
Is this the same issue that you are all seeing?
If so, I hope this pattern helps find a solution that does not involve a macro/extra diff step...
It has to be a setting somewhere, or a side effect of clicking something, since it is 100% reproducible per each of these machines. Even if it is something silly like which option you choose for your initial environment layout (VC++, VB, General Development, ect...)
I use WinMerge as my diff-tool and I enabled the moved block detection. It doesn't quite fix the issue, but it makes visualizing the differences a little bit more bearable.
I think I've found the reason for this shuffle. At least in VS2008.
If you install the x64 compilers, VS will order projects as:
Debug|Win32
Debug|x64
Release|Win32
Release|x64
If you don't it will order them like:
Debug|Win32
Release|Win32
Debug|x64
Release|x64
So make sure all your peers have the same compiler set installed, so it won't shuffle.
Tested it and this behavior appears to be reproducible.
Which version of Visual Studio are you seeing this in?
I do a lot of work with .vcproj files (we maintain versions of the project files for our libraries in multiple Visual Studio versions, and I'm always diffing and merging the things) but I've never seen this behaviour.
My team at Adobe has seen the same thing in vs2008. Just a basic Debug/Release, win32/win64 project gives you 4 configurations and random shuffling. Several people have tried to figure out when and why devstudio reorders, but current thought is the sort key is a keyword hash - hence semi-random. We've given up and in code reviews just summarize the "real" changes.
Related
I tend to use Regionerate quite extensively for reorganizing my code files. My only problem is I can't get it registered with VS2012. I've abandoned VS2010 fully in favour of VS2012 and it's galling to have to flip back just to run a macro to reorganize code files. I've never tried writing a VS addin before so I'm not at all familiar with the object model or how to register - seems the old addins are more complicated to install than the VS2010 extensions! I've also looked through the WIX setup XML and tried replicating the registry keys to no avail.
Does anyone know how to either register Regionerate with VS2012, or is there an alternative (free and which is maintained!) extension that provides the same functionality?
Two things needed for registration:
It looks like VS2012 doesn't read from the HKLM...\11.0\AutomationOptions key at runtime, only at first run. The corresponding key at HKCU...\11.0_Config\AutomationOptions needs to be set as well.
A new .AddIn file needs to be created with a Version of 11.0
If you do that, Regionerate will appear, but will hang Studio when you try to use it. The Regionerate code has a bad version check ("not equal" instead of "less than") that will get stuck in code that doesn't work for VS2010/2012. Unchecking "Automatically collapse regions" in Regionerate settings might be enough to avoid the bad code.
I made a new version that fixes the version check and has the correct install pieces for VS2012. You can download the installer and changed source files here:
https://skydrive.live.com/redir?resid=2FEB8D1988F04D77!565
This is what you need to do to make VS2012 compatible Regionerate (0.8.0.1) by Frank Racis work with Visual Studio 2013.
Modify this file: C:\Program Files (x86)\Regionerate\Regionerate.VS2012.AddIn
Change version from 11 to 12: <Version>12.0</Version>
Add the following string value in your registry:
Location: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0_Config\AutomationOptions\LookInFolders
Name: C:\Program Files (x86)\Regionerate\
CodeMaid is a free and actively developed alternative. It has nearly all the features of Regionerate, plus some new stuff. One thing I really like is setting it to organize and clean unsaved files every time I build.
Source code that compiles fine on other peoples environments won't correctly work in my environment. When I do a rebuild the compile occurs but when visual studio goes to move the exe from /obj/debug/{solution} to /debug/{solution} it cannot find the exe in the /obj/debug/{solution}. To make this even more crazy even after I reinstall visual studio it doesn't work. On other people environments it works find. Please note that this is a windows mobile 6, compact framework 3.5 project, Visual C++ project.
EDIT: Visual Studio 2008 is being used.
EDIT2: After looking at the logs again come to find out it says it is compiling but it isn't really compiling. Interesting enough it doesn't throw any errors until it tries to link the code. When it goes to link the object files, they aren't there and it fails.
I got TWO Release folders: one in the solution folder and one in the project folder. The former contains the .exe file, the latter does not.
In the solution properties page, check whether the path you are expecting the exe to be is same as the one specified in Linker -> Output file.
Another obvious mistake could be, check what build configuration you are building. You might be doing a release build and expecting a debug executable file :) I have done this a few times.
Maybe VS creates the exe, and before it tries to move it to the final destination your virus scanner grabs it and removes it, or moves it to a save location.
I just wanted to chime in and ask: have you looked for the *.exe file name from the directories above? What I found in my case was it was writing to the directory right above the /release subdirectory. Not sure how I missed that detail, but I did! I suppose it never occurred to me earlier because I saw the buildlog.htm being written to the /release subdirectory, and the very existence of the directory itself. In my case it was compiling, linking, etc. I just wasn't able to see the *.exe in that /release subdirectory.
There are two subtly different paths. I was looking here, which doesn't exist:
C:\Users\james\source\repos\CppHelloWorld\Release\CppHelloWorld.exe
The actual exe is here - note the path contains the x64 platform that it was built for:
C:\Users\james\source\repos\CppHelloWorld\x64\Release\CppHelloWorld.exe
In general, the path seems to be:
$PROJECT_PATH\$PROJECT_NAME\$PLATFORM\$CONFIGURATION\$PROJECT_NAME.exe
If the exact same solution works on other machines, then it's an environment problem and no amount of looking at the project, linker, etc is going to resolve this. What is different about the environments? Are the same service packs and QFE's applied for not just Studio, but also the OS? Is there a difference in processors (64/32-bit)? Are your permissions the same? Do you have the same SDKs installed?
I'd agree with Shahi that just trying to build a "hello world" app against the same SDK and see if it will compile is valuable info.
I had exactly the same problem. Just close Visual Studio and reopen it again (basically restart it) and it should work.
In my case, my network security team released an unannounced security update that preventing me from creating any .exe files. I figured that out at midday after trying all the solutions (+ more) here.
Perhaps you do not have write permission to the output folder? If you are running on Vista/7, is your Visual Studio running as elevated?
I've found this to be random for myself in now VS2016. My work around has been to just create another project and copy the contents from the one with out the .exe to the new one. For some reason the new one normally will have the proper .exe and location needed. While this isn't a complete solution at least it's been working for me for the time being.
It happened with me today:
TL;DR; You might be using some C# code in your project who belong to a language version which is not supported by the .NET Framework version targeted by your project
Details:
I had two projects in my solution. One project was already existing. I added a new project targeting most recent .NET Framework v4.6.1 supported by Visual Studio(VS) 2017 class library project template. I used some C# language features which is present in C# v7.0. In such a case, VS can compile the project but can't create the output in bin directory.
Eventually I had to merge the new project code files into the existing old project which was targeting .NET Framework v4.5.1.
So I changed the target Framework version to the latest .NET Framework v4.6.1 for the existing projects also. Then the old project also started supporting my newly pasted C# language features.
In my case, the error appeared after I cloned my solution on a new machine.
I did not realise that the newly-cloned solution had AnyCPU set by default, when in reality my solution only supported x64. The compiler, however, did not return any error.
What pointed me in the right direction was the Output log, highlighted that of the 4 projects my solution was composed of, one of them was always skipped, i.e. only 3 were actually compiled. Scrolling up a bit the log, I noticed some message similar to MSIL mismatch between CPU versions.
Switching from AnyCPU to x64 solved the error for me.
(I then deleted the AnyCPU option from the Configuration Manager to avoid this issue in the future)
If you create a new "hello world" WM project, does it work?
If so, you can compare the solution files to check for differences that can cause this.
As far as I could tell, you need to "Save All" before building.
In short: is there a way to compile and run single file in NetBeans or Visual Studio without having to setup and tinker with projects?
I'm currently using code::blocks as my IDE. It's fast and very simple: perfect for my needs as a begginner.
I wanted to dive a little deeper and try out a more advanced IDE such as NetBeans or Visual Studio. It appears I have to mess with projects and have a setup that seems overkill for having to compile and run one very simple .c/.cpp source file that contains less than 50-100 lines of code etc.
Is there a way around this?
You always have to setup a project - this is where information about libraries etc is found by the IDE, so it cannot do without. If you just have one file, and not a lot of dependencies you could just stick with a plain editor. Once you want auto completion of functions, refactoring, etc... you have to store the information about what is relevant somewhere, and the some sort of 'project' will become necessary.
Is there any tool that can convert a large and complex* Visual Studio 2005 (or 2008) Solution into a SCons project?
* Lots of projects and multiple configurations on multiple platforms/compilers
Probably not, and even if there were, SCons gives you significantly more transparency and flexibility about managing your build than visual studio does. As a starting point, it's best to do each one in turn.
Create a new makefile project
Clone the source from one project to another
Invoke scons from the makefile command.
Replace the dependancies on the old project with the scons version.
Test
Repeat from 1. with each project.
Once you've done a few projects, it's pretty easy to refactor the major differences between build types (shared libs, static libs and programs) and platforms into a module of common scons helpers that can be imported. On windows, consider groups of flags for things like debug and release builds, standard library linkage and exception handling.
Also, things to look out for include:
If you're doing cross platform builds, consider the differences between the linking models with respect to the effects of missing symbols.
What you'll do to deal with manifest files and invoking the visual studio tools.
Variant build directories (debug/release) can be tricky at the start. Start simple, and enhance your build once you're sure it's necessary.
The following script looks promising. I may give it a whirl: the reason the by hand solution isn't completely practical due to the sheer scale of the solution in question: it has hundreds of projects. This is why I was thinking a script that would generate SCons modules would give me a starting point.
Unfortunately porting the solution in question to SCons by hand would be a project in itself!, although I do admit it would be the 'correct' way to do it.
I've been programming in Linux/UNIX for several years now, but recently I needed to do some stuff in VS2008. I had difficulties with understanding how VS organizes work. Do you know any resources (free web pages preferred, but books also acceptable) which would show me a general picture and explain at least some details? Examples welcome, comparison with typical UNIX stack very welcome.
I don't need a language (C#/C++/VB/...) reference/guide; I've seen some of them and none of them seem to suggest how to work with VS efficiently.
You might be interested in introductions to MSBuild, the project format of Visual Studio. Whereas in UNIX you have a autoconfig script, and Makefiles, VS2008 allows most configuration through right clicks and menu options.
A second area of interest will likely be build configurations. Instead of re-running the configure script on different targets, or for different stacks, you specify targets with the configuration manager. Once you select a new configuration ("x86", or "Release", or custom ones like "Production"), VS churns for a while, as it updates the Intellisense of your new preprocessor definitions, for example, and Resource files. Your "Debug" configuration will likely define the macro "DEBUG", so you can use regions surrounded with #ifdef DEBUG, for example.
Visual Studio organizes common groups of source files into "Projects", which can be referenced by one or more "Solutions". Projects establish interdependency on one another, and external libraries. If you look at the structure of the projects in the Microsoft Enterprise Library, you will notice that there are several different Solution files (*.sln) which encompass different groups of common project files. You might have a different solution file, for example, if you want to reduce load/compile time, by not loading the unit test projects with every build.
So, analogies:
UNIX way:
# ./configure
# make
# nano Makefile
# make
VS2008 way:
# (Set up "Project Properties", Conditional Compilation Symbols, Build Paths, all from GUI application)
# (Click Build)
# (Change Configuration)
# (Click Build)
I don't have any links for you, but:
Visual Studio can open one and only one Solution at a time
A Solution may have zero (not very useful) or more Projects
Code (in whatever language) goes into projects
Projects can have any number of files and/or directories
Projects can reference files anywhere, not just within their own directory structure (though few do)
Visual Studio is a very flexible and powerful IDE. I think the best way to get the big picture is to build that big picture yourself in your own terms by using the heck out of it.
Build configurations and project properties are definitely two areas you will want to focus on.
You should explore the various options and configuration switches for generating assemblies and how they are managed in general. Learning the various build options and how assemblies are managed can save you headaches down the road.
The VS debugger is a thing of beauty and I recommend investing some time in exploring its capabilities. I recommend you familiarize yourself with:
Breakpoint management (especially the breakpoint window) and also conditional breakpoints
The Watch and Locals windows
Thread and Memory windows and tools
Immediate window (often overlooked and underrated if you ask me)
Finally, you should take a look at some tried and tested tools and plugins and get familiar with them. I would personally recommend ReSharper, Dependancy Walker, and .NET Reflector. ReSharper is an excellent productivity tool and Dependancy Walker and .NET Reflector are excellent analysis and debugging aids
Here's a couple of handy stackoverflow threads:
Do you have any recommended add-ons/plugins for Microsoft Visual Studio?
Favourite Visual Studio keyboard shortcuts
Have you considered installing cygwin and gcc? If you're looking to write a console app, it might just do the trick.