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.
Related
I am currently trying to write a plugin for visual studio that accesses the bin folder of the currently open project in Visual studio. However, all the solutions I have come across simply return the bin folder and directory of the plugin that is I am writing. For example, I have used the method detailed in the article below, which claims to return the current project's directory.
How to Access Bin Folder of Active Project using visual studio 2010 add in
path = System.IO.Directory.GetParent(Environment.CurrentDirectory).Parent.FullName;
System.Windows.Forms.MessageBox.Show(path);
Is there anything I am missing on how to make this work?
A Visual Studio project can have several project configurations, each one with a different output build folder that is set in the project properties window, Compile/Build section, Build output path. Furthermore, the output build folder can be absolute or relative to the project folder.
The code of this article gets the absolute output build folder for the active configuration of each project of a solution:
HOWTO: Get the output build folder from a Visual Studio add-in or macro
http://www.mztools.com/articles/2009/MZ2009015.aspx
I'm using a Makefile project in Visual Studio 2012 express just fine. However, regardless of the Build Command specified, Visual Studio always makes an 'obj' folder containing empty subfolders obj\Win32\Debug and obj\Win32\Release.
To reproduce the problem, simply create a "Visual C++ - General - Makefile Project" and use a DOS command like 'dir' in the Build Command Line. As soon as you build, the empty obj\Win32\Debug folder will show up.
I can simply skip these in my Mercurial ignore file but it'd be nice to find a fix. Anyone know how to make Visual Studio not generate these empty folders?
Found a trick: to set the intermediate output directory on an existing directory. I modified the project file by hand and added this:
<IntermediateOutputPath>$(ProjectDir)</IntermediateOutputPath>
inside the configuration PropertyGroup. I used the project directory, which obviously already exists. No more useless obj directory!
The obj folder represents VS' own metadata about your project for intellisense support and designer support (for WF/WPF apps). For the most part you can ignore the folder completely without issue.
On occasion though this data can become corrupt and cause VS to show invalid Intellisense options and the workflow/WPF designer can cause errors. Closing VS and deleting the obj folder will quickly resolve this though.
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
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 get this error in Visual Studio 2008 when developing a ASP.NET Web Application Project.
Unable to load referenced library
'Path-to-DotNetNuke\bin\file.dll': The
process cannot access the file because
it is being used by another process.
This is a DotNetNuke project with multiple modules. IIS loads all assemblies from /bin folder under the application root.
The projects in the solution are in their respective /DesktopModules/ProjectName folders and compile to a bin folder under the project.
The error occurs after I compile the solution and copy all the projects' dlls to the /bin with a script. Visual Studio does not let me recompile, but if I restart it, everything works ok. This is really annoying when recompiling and testing the whole solution. You have to restart Visual Studio between every recompile.
I couldn't find any file locks with Process Explorer when Visual Studio shows this error.
[UPDATE] There is an old MSDN document that tells you not to build all DLLs to a single folder if you reference any over 64KB DLL there. Particulartly, the document says:
It causes the build process to fail
with file lock errors when a
referenced assembly exceeds 64 KB in
size.
We do have references to over 64KB DLLs in /bin folder and copying recompiled DLLs there seems to trigger this, at least with VB IDE's background compiler.
The error occurs after I compile the solution and copy all the projects' dlls to the /bin with a script. Visual Studio does not let me recompile, but if I restart it, everything works ok.
I would suggest setting the output directory of each of your projects to be the bin directory of the DotNetNuke website. This will help you to avoid the manual step of copying files altogether.
To set the output directory of your project: Right click on your project in Solution Explorer and select properties. Select the build tab, select All Configurations (at the top) and set Output Path to "..\..\bin" (near the bottom). This assumes your project file is in it's typical spot within the module's home directory (e.g. DesktopModules/YourModule/YourProject.csproj) otherwise you can navigate to your web site's bin directory with the adjacent browse button.