Today I have upgraded a VS 2008 project to VS 2010 simply by opening the solution file (right click -> open with -> Visual Studio 2010).
I have successfully built the project (debug and release configurations). When I run the project within Visual Studio I get the following weird error:
Notice that \.\? The actual path on my computer is C:\xxxxxx\Application\Debug
What is the cause of path being messed up? And how to fix it? Anyone knows?
BTW. The executable is in \Debug folder and runs fine if I click on it
EDIT
Language: C++ (MFC)
The Output Directory was hardcoded in VS2008 configuration properties to:
Output directory: .\Debug\.
Intermediate directory: .\Debug\tmp\.
If I change that to $(SolutionDir)$(Configuration)\ and $(Configuration)\ respectively the output folders are messed up completely: the \Debug folder is full with .sbr files and all the object files are located in \Debug\tmp after I build the solution. Even though when I build (after changing the output configurations) it says successfully built, but it can't find the .exe file
There are several third party libs but I don't see how that would affect it in any way.
[SOLVED]
VS 2010 apparently handles the project configurations differently than VS 2008. Having the output path hardcoded in the 2008 configurations caused confusions for 2010. I have replaced the hardcoded paths with VS defaults (using variables instead) and the problem was solved
Related
Lately we (the team I work with and myself) have been seeing something strange between the build results of MS-build and Visual Studio (2015).
The situation
The team I work with has been tasked with refactoring an older and rather large c# project that contains many (150+) projects all bundled into a single sln file. As to be expected merge conflicts occur in the sln file during our work and one of the team members resolved this conflict incorrectly. Leaving the sln file with a missing project reference.
From here on out the behavior of the project is different on 3 location. They are described below
Visual studio of the developer that origionally made the mistake
(note that I assume that this developer has not cleaned his solution)
This programmer has already build and run the project (using visual studio 2015 professional). So all compiled dll files are in the prorammers output folder. This means that Visual studio does not notice that a reference is missing. The programmer can build, run and test the application without any problems.
The build server
The build server (Jenkins) does not run Visual studio, but it uses MS-build 14 to compile the source code. The Jenkins server is configured to run with pipelines, described in groovy. We call ms build by invoking a bat script that runs MS-build over the command line. An example:
"C:\Program Files (x86)\MSBuild\14.0\Bin\amd64\msbuild.exe" "TheSolutionFile.sln" /property:Configuration="Debug" /property:Platform="Any CPU"
Somehow the build will succeed even with the incorrect sln file. I suspect that ms build resolves its own dependencies as the workspace on the buildserver is clean (completely empty) so no leftover dll's can fool the system. (am I correct in assuming this?)
The other team members
The other team members will eventually pull the changes of the broken sln file and they will be in for some 'fun'. When you do not have the dll files in your output folder Visual studio will attempt to rebuild the missing dependencies. But since the references cannot be resolved it will fail and start stacking errors about missing meta data. In the team we all use Visual studio 2015. But we also tried it with 2017 and ran into the same result. The person who originally made the mistake can also end up in this group of he cleans the solution.
The Question
Obviously we are not happy with the fact that the build server accepts the build with a broken sln file (a developer pulling the latest version cannot compile or run the program). Is there a way to get the last two situations in sync (so ms build not accepting a 'broken' sln file to compile)
Is there a way to get the last two situations in sync (so ms build not accepting a 'broken' sln file to compile
That is because MSBuild.exe from command line does not have the same build environment as Visual Studio. You can call MSBuild.exe from VS command promt which has the same biuld environment as Visual Studio.
If you want call ms build by invoking a bat script that runs MS-build over the command line, you can use devenv.exe to build the solution/project from command line:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE>devenv "D:\TestSample\TestProject\TestProject\TestProject.sln" /build Debug /project "TestProject\TestProject.csproj" /projectconfig Debug
For the detail information about devenv.exe you can refer to Devenv Command Line.
Hope this can help you.
My advice:
The .sln file is just a collection of project files. Create a brand new one, and add in your proj files one by one. Forget the code-merge-conflict-resolution drama.
The voodoo in the .sln file is too much voodoo. Let VS do it for you...as you add each project in, one by one.
File / New / Project ::: Installed / Templates / Other Project Types / Visual Studio Solution ::: Blank
Solution.
One other hint. If you still have issues, then open up each proj, and any "by project" references, delete them and re-add them. Sometimes the GUID's get mixed up, especially over a long code-merge history.
When using Visual Studio 2008 under MPI cluster debugger, each execution is launched without moving the generated binaries (.exe, .lib).
When using Visual Studio 2010 under MPI cluster debugger, each execution is launched by moving the generated binaries (.exe, .lib) in two directories :
- all the .lib are first copied inside the .exe directory
- once done, all the .exe directory is copied inside a temporary directory containing by default the user login name.
So with Visual Studio 2008, each execution of a medium size C++ project takes a few seconds to be launched.
With Visual Studio 2010, each execution of a medium size C++ project takes several minutes.
Is there a way to change the behaviour of Visual Studio 2010 in order to work like Visual Studio 2008 did ?
Or if not possible, is there a way to improve the launching time of each execution ?
I am using MPICH2 for MPI and execute my project only locally (localhost/2 environment with -localonly mpiexec argument), for Visual Studio 2008 and Visual Studio 2010.
Thanks for any help.
Do review the MSDN page that describes the MPI debugger configuration. Note how the descriptions of the Deployment Directory and Working Directory properties describe what you see.
However, you are not actually debugging on a cluster so you don't need to have these copies made. Without otherwise knowing what your config looks like, or any way to test it, I'd guess that you have these properties set wrong. As documented on the page, for local debugging you should select:
Deployment Directory: none
Working Directory: the output directory of your project.
Which should avoid the copying.
I have some videofiles in our SVN repository alongside the sourcecode of my application. After checking out, the visual studio project is built using cmake.
my code needs to load the video files and it works well when running the application out of visual studio - but when the exe file in the release/debug folder is doubleclicked, it crashes because the relative paths are not right anymore. aparently when running it from within visual studio, the folder where the .sln file lies is considered the root of relative paths.
how can I refere to the videofiles from the code, such that the application works if i run it within visual studio as well as if i double click the exe in the release/bin folders, without to duplicate the videos? (they are quite big)
I need to do this because I have to hand in my application such that it can be compiled and run out of the box as well as executed without visual studio.
You can change your project's settings to make the IDE's behaviour match double-clicking on the executable, and then fix your relative paths.
For VS10/VS11, in the project's properties page, at the top select All Configurations from the Configuration: list.
Then select Configuration Properties->Debugging and set the Working Directory to $(OutDir)
Beware that running the executable from the command prompt in a directory other than $(OutDir) will still fail.
I've been using CMake for quite some time to generate VS 2008 solutions to build a program, its installer, and its packager (as well as several test programs). In order to run, the program needs several dlls which the install project puts into a bin directory, along with the generated executable. Under VS 2008, if I want to debug the created program, I build the INSTALL project, and then click Debug->Start Debugging. The first time I do this after generating the solution, this presents me with a dialog from which I can browse to the bin folder and then the desired executable.
However, under Visual Studio 2010, after clicking Debug->Start Debugging, I do not get the dialog, but rather get the message that it can't find the ALL_BUILD program (which does not, and should not, exist). I can change the start up project to be the executable in question (or right click on it and choose debug), but then that loads the executable from the wrong path and is therefore unable to find the dlls. I know that I could either add the dlls to my system path or copy the dlls into the same directory where the executable is initially created, but these are less-than-ideal solutions (for testing and portability reasons), and these steps were not required in VS 2008.
This is the exact same CMakeLists.txt file for both cases, and the exact same source code. The only difference is that CMake is run with the "Visual Studio 9 2008" generator in the first case and the "Visual Studio 10" generator in the second case.
I can run the generated program from the bin directory using Windows Explorer, but I am not able to debug it (e.g., step through a problem area line-by-line).
You need to edit the debug properties of your start up project so the command line and working directory match your install location.
I'm working on my first project in Visual Studio and I haven't used Windows much since '05, so please bear with me.
I've got my project open in Visual Studio 2008, and I'm trying to open a particular file for editing, but I get an error that says
"c:\path\to\file
Cannot open file.
I've verified that the file exists, and I can open it from Windows Explorer, but nothing from inside Visual Studio, any ideas?
I'm not familiar with Visual Studio, so my terminology might be incorrect.
The file appears in the tree in the Visual Studio Explorer pane, so I double clicked it, and got the error. The error said nothing more than the file path: Cannot open file.
How can I check permissions/ACLs in Windows? I assumed that since I could open it in Windows Explorer, I would be able to open it in Visual Studio.
And it's a .cpp file.
You may want to right-click on the file in the tree, and delete it from the project.
Then, add back an existing item.
Hopefully that will fix the problem.
Though I'm not familiar with this specifically, if you just want to move forward, I'd recommend creating a new project type and just adding all the existing files to it. Should be quicker and easier than diagnosing what could be many issues.
Other things to check: encoding type of the project file, permissions/ACLs (can you open that actual file from an unelevated VS prompt, for instance), etc.
Additionnaly to the other answers, I found out that this problem may arrise if the target .Net framework version specified in the project file isn't installed.
This seems to prevent visual studio from opening all the files contained in the project, and showing the "Unable to open file " message.
Correcting the version (in the csproj file or in the settings), saving and reloading the project fixes the problem.
I had same problem, my project were build on (.Net 4.5), which I uninstalled on my PC and replaced by (.Net 4.8), so just replacing project's target framework to the one which is installed "in my case (.Net 4.8)" should fix it.