Using content from the project in tests - unit-testing

I am working with Visual Studio 2010 and it's integrated testing functionality.
I have an XML file in my project which is set to copy to the output directory. I can access the file just fine when I compile and run the project. But it doesn't exist when I attempt to access it within a TestMethod.
It looks like the test is run with the working directory set to an "Out" directory created within the TestResults directory. I can set a breakpoint before I use the file. If I then copy the file into this "Out" directory and continue running the test it accesses the file properly. But that is not really how I want my automated tests to function.
Is it possible to tell VS to copy the build directory into this working directory?

I found somewhat of a solution. Though I'm not too happy with it.
Under the Test->Edit Test Settings I edit the current settings.
Under the Deployment tab, check the Enable deployment checkbox. In the Additional files and directories to deploy add your bin\Debug directory (looks something like src\LocalModels.test\bin\Debug)
I suppose you could add each file you need and it would be a bit faster. It all seems a bit ridiculous.

Related

Project File Not Found while attempting build in Azure DevOps Pipeline

I have a solution that has 6 projects, some of which are in separate DevOps projects. I am attempting to setup a build pipeline in Azure DevOps and my repository is already located there. Regardless of location, I continue to get errors that the csproj file cannot be found for any of the projects. The build cannot continue without the csproj files (obviously).
I have tried to move the .SLN file to the root folder, inside the specific project file and still get this error. I have also looked at the relative paths in the .SLN and attempted to manually modify them without any change.
Additionally, I used the vanilla configuration for the build pipeline before attempting to change path locations etc.
Here is the structure of source control:
Source structure
The 6 projects highlighted yellow are included in this solution.
Here is the output errors from the build in DevOps:
Output errors
I also tried adding the locations explicitly without any luck. By default, the location path was just $/PermitInspector/PermitInspector which is the location of the .SLN file. (Which is where I started with the attempt to automate builds).
Any suggestions would be helpful and I would be happy to share additional information or screen grabs that might be useful, but this is all I can come up with so far.
I was able to resolve the path issues by applying path filters under the build configuration in DevOps. There is a single work space and 3 of the projects are located in a root folder within the work space and the other 3 projects were in a separate root folder. The main issue appeared to be that the solution file is located inside the second root folder so I had to explicitly define the path to the other project files. By default, the only mapped work space was to the location of the SLN file. Now if I can just get NuGet restore working for the sub-projects! Thanks again,
Correct mapping that fixed the issue

Program works in VS 2013 but not the .exe

I have made a test program in Visual Studio 2013 using Direct X 11. It consists of a simple sprite which rotates slowly based on a timer implementation. The program loads and runs fine using F5 or Ctrl-F5, but when I try to open the actual created .exe (in my \Debug folder) it just shows the window then closes instantly.
Most of the answers I have read on this issue correspond to loading the .exe from inside visual studio. I have also tried Release mode but the same thing happens.
Sprite files are kept in your project folder. The default run-location from the Visual Studio IDE is the project folder of the project which you're executing. That is, normally it executes from the directory where your .vcproj or .vcprojx file is kept (and that is often one folder below your solution directory folder, where your .sln file is kept).
If your project runs correctly from the IDE, but fails to run directly from the debug folder, it is highly likely you are relying on project data files that are kept along side your source files in the project folder. When run from the Debug folder, those files are no longer visible because Debug folder is your working directory; not the project folder.
There are a number of ways to solve this problem, each with its own merits. A few options are:
Post Build Step
Make a post-build step for your project that copies your data files to the $(TargetDir) location with your project. These files will then be visible in the same directory as your executable.
Benefit: Its easy.
Drawback: It will always run if you click "build solution" even if the data files are "up-to-date."
Custom Build Targets
Add your data files to the project and write a Custom Build script that performs the same copy, but also establishes an output dependency file(s).
Benefit: Almost as easy as #1, but a little more tedious.
Drawback: You may have a lot of data files and each will require its own custom build step. (Note: you can multi-select all the data files in your project, and if you're creative with the built-in macros you can have them all use the "same" build rules and commands).
Embedded Resources
Add the data files as custom resources to your executable.
Benefit: Your project no longer requires data files side-by-side with the executable since they are embedded in the resource table of your EXE module.
Drawback: Custom code is required to dynamically load the custom resources from your executable's resource table rather than off-disk. It isn't difficult at all to do, but is additional work.
There are other options as well, but I hope this gives you some ideas to start with.

c++ executable program test

I have been following some tutorials for c++ game programing. I am kind of new to c++ and I'm using Microsoft Visual C++ 2010 Express IDE. I'm working on creating a game, and when I run the program through the IDE, it shows the grass sprites as expected. But when I run the .exe file from the Release folder, it shows weird images. and when I run the .exe file from the debug folder I get a grey screen. Can anybody tell me why this is happening?
I hazard to guess that your sprite images are kept as data files in your project folder. With that I offer the following premise:
The default run-location from the Visual Studio IDE is the project folder of the project which you're executing. That is, normally it executes from the directory where your .vcproj or .vcprojx file is kept (and that is often one folder below your solution directory folder, where your .sln file is kept).
If your project runs correctly from the IDE, but fails to run directly from the release folder, it is highly likely you are relying on project data files (images in your case) that are kept along side your source files in the project folder. When run from the Release folder, those files are no longer visible because your the Release folder is your working directory; not the project folder.
There are a number of ways to solve this problem, each with its own merits. A few options are:
Post Build Step
Make a post-build step for your project that copies your data files to the $(TargetDir) location with your project. These files will then be visible in the same directory as your executable.
Benefit: Its easy.
Drawback: It will always run if you click "build solution" even if the data files are "up-to-date."
Custom Build Targets
Add your data files to the project and write a Custom Build script that performs the same copy, but also establishes an output dependency file(s).
Benefit: Almost as easy as #1, but a little more tedious.
Drawback: You may have a lot of data files and each will require its own custom build step. (Note: you can multi-select all the data files in your project, and if you're creative with the built-in macros you can have them all use the "same" build rules and commands).
Embedded Resources
Add the data files as custom resources to your executable.
Benefit: Your project no longer requires data files side-by-side with the executable since they are embedded in the resource table of your EXE module.
Drawback: Custom code is required to dynamically load the custom resources from your executable's resource table rather than off-disk. It isn't difficult at all to do, but is additional work.
There are other options as well, but I hope this gives you some ideas to start with.
I use VS2008 and try to answer your question. Right click on the project and select properties on the bottom of popup, then go to Debugging under Configuration properties. You can see command you run and arguments you pass in IDE. I guess you miss some parameters.

TFS Build Server with project with "custom build tool"

I'm setting up an TFS 2010 Build server.
But I currently have the problem that projects with an "custom build tool" won't build because of "no access".
The projects are C++.
The custom build tool is "Pro*C". Basically, you have an *.pc file, and it generates an *.cpp file.
But on the build server, the directory/files are readonly. So it will crash on "no access".
I have tried to remove the *.cpp file from TFS. So that the generated file does not exists. But apparently the folder is also readonly and won't allow to create a new file.
Does anyone has a workaround for this?
I would suggest one of these options:
Don't put the .cpp files in source control if they are generated by the build process
Change the settings for Pro*C to write its output files to a writable intermediate folder
Add a build step that copies the problem files to an intermediate location for processing
Add a build step that forces the file access on those files to be readable for processing
If you only need to build those files occasionally, then build them manually with Pro*C on your developer machine and check in the results, so you don't waste time unnecessarily rebuilding unchanging files with every desktop or build-server build.
There is a project called MSBuild Community Tasks, which can be downloaded from http://msbuildtasks.tigris.org/. I used it for my own for an automated tfs-build.
It provides you with several extensions for your msbuild-project. One of this is the so called Attrib task, which gives you the opportunity to change file (and probably folder) attributes out of you project. It's not listed in the table on the website, but its documented in their documentation. As a sample from their documentation, you can add the following line to a target of your choice:
<Attrib Files="Test\version.txt" ReadOnly="true" Hidden="true" System="true"/>
I think this will also work for an item-group as follows
<Attrib Files="#(AllYourFiles)" ReadOnly="true" Hidden="true" System="true"/>
If you want to use it, don't forget to install it on the build server. ;)

Where do data files go so the Microsoft Visual C++ 2008 debugger can find them?

I am writing code that opens an istream object on a file specified by the user. I want to be able to run the program in the debugger and just type the filename (eg data.txt) at the prompt, not the whole path. I haven't worked out how to do this inside the IDE so I have been saving my .txt file to the debug folder and running the .exe file, but that means I can't step through the program. How do I make it work inside the IDE instead? Thanks.
you can set the working path of the executable (project properties->Debugging->Working Directory), which leads the debugger to start the executable with that path as working directory. This has the advantage that if you set the same path for all your configurations (Debug/Release/...), you only need 1 data.txt on your entire system, which is especially nice if you want to change data.txt or it's name.
I am not sure I understand exactly the problem - is it that your data file is part of the project, but is not in the executable folder when you access it, or is it that the datafile is at another location? If the former, and the data file is part of the project, right-click on the file, and set the Build Action property to "Content". That way, it will get copied to the bin/debug folder where the executable runs when you debug.