Relative paths with NCover and MSTest.exe - mstest

I know this is stupid, but I can't figure it out. In our solution, we specify the relative paths to a file one of our tests needs as -
../../../TestSuite/IniTestFiles/LocalRedir1.xml
Now, this works fine when running the testing out of VS with MSTest.exe. However, in NCover all of the tests fail. Does anyone know how I can go about fixing this? I can't move the file's location. Thanks!

Try setting the working path of NCover //w.
This way the ../.. will be relative to that folder.
You may also contact support
Joe Feser
NCover

Related

Could not find a part of the path 'AccessibilityManagerCompat_AccessibilityStateChangeListenerImplementor.class'

while building xamarin forms android app in debug mode
I am getting following error
Unable to remove directory "obj\Debug\90\android\bin\classes". Could not find a part of the path 'AccessibilityManagerCompat_AccessibilityStateChangeListenerImplementor.class'.
unable to find resolution for this as line number is not shown
Your path to the solution could be too long. I solved this by moving my solution closer to the C drive root. Also take into account that your application might not have sufficient rights to access that location, so make sure you give the necessary access rights.
Manually delete your bin/obj folders from your Solution, and then try to rebuild.
Usually this does the trick, since it is trying to remove a class that he cannot find a path of.
Manually deleting the obj\Debug\90 folder and subsequent build worked for me.
Clean and Rebuild didn't do it for me.
You need to make sure that the path is short and you dont have any spaces or special characters in the path to your project
The latter one was the issue that haunted me for a while.
For example: C:/abc xyz/ProjectName/... is unacceptable because there is a space between abc and xyz.
I don't exactly know why but this works for me
Happy coding!

Compiler warning after install Xcode 7 Directory not found for option '-F ...'

I check this answer with no success.
Maybe sounds obvious but I look for inside the path and effectively does not exist the path, but this path is used for Xcode and not for my code (at least not that I know it)
The folder suppose to be here the but it does not exist (create the folder manually but does not fix it)
Somebody have an idea ?
I had the same problem, here's how I solved it:
Go to the "Build Settings" of the Tests Targets (Make sure it's the "Tests" files with the white building block logo) and erase the Framework Search Paths.
Since you claim that the path doesn't exist, I suppose you were looking under the normal file instead of the "Tests". At least that was my mistake.
Good Luck!
I changed the last "Developer" in the Tests target's "Frameworks Search paths" path to "System" (...iPhoneOS9.0.sdk/System/Library/Frameworks) because there is a System/Library/Frameworks directory. My code builds and the warning goes away.
Ups !!
I have the problem in the Test Compiling.
I delete the path and fix it.
I have the same problem. I can temporarily rectify the issue by selecting "Product - Clean" from the menu. It soon returns though.

Why does my working directory change to C:\Windows\System32 when I use a Console subsystem

I'm using SDL in VS2013 and I'm trying to load an image from the folder that my working directory should be using a relative path. Which is where the .vcxproj files are. However I discovered that the working directory is not the folder it should be, it is actually in C:\Windows\System32. I have realised that this is only the case when I go to linker, system and then change the subsystem to CONSOLE. In a WINDOWS subsystem it uses the correct working directory. Why is this happening and how do I fix it?
I think it may have something to do with VS2013 using cmd.exe which is in the system32 folder but I cannot be certain and would not know how to fix it even if that is the case.
Hmm...I don't think I've ever had that problem, and I always write with the console window. Have you tried just making a new project to see if maybe something got set in your properties by accident or something? I would give that a try, or maybe re-install SDL..? That's weird, sorry I don't have better advice!

TFS 2013 automated build: Is there a way to run the tests from the src folder

I'm currently using the default build process template in TFS 2013 for my automated builds.
I've configured the OutputLocation parameter to be AsConfigured to get the same folder structure as my Visual Studio solution (there are multiple projects in the solution and I don't want them all to be dropped in the same folder).
The problem is that when the build process tries to run the tests, it looks for any assembly under the bin folder, while my build configuration makes it so that there is only a src folder.
Is there a way to specify looking into the src folder instead? Shouldn't it be the default anyway when using the AsConfigured setting?
Edit: Just to make it clear, there are usually 3 folders generated when running a TFS automated build (src, bin, tst). When using AsConfigured for the output location, there is no bin folder. I tried a suggestion which required changing the Test sources spec setting of the build process, and I get the same problem as before:
There were no matches for the search pattern C:\Builds\8\MyProject\MyBuildDefinition\bin\***test*.dll
What I ended up doing is using a PowerShell script as a post-build event to copy my test assemblies to the bin folder of the build.
There are PowerShell scripts made available for TFS 2013 on CodePlex, and I modified this one slightly to accomodate my needs.
By doing this, I was able to use the default settings for running the tests, and it worked like a charm.
In your build definition, change the value of setting "Test Sources spec" to ***test*.dll (assuming your unit tests assemblies are suffixed with .test.dll)
EDIT: Please use **\*test*.dll;**\*test*.appx
Try to use this file masks: ..\**\*test*.dll
It works for me.
I have "AsConfigured" setting on for X64 platform that places the binaries into src\x64\Release\ (and it used to place them into bin\x64\Release\ without that switch). So, I ended up using ..\..\..\src\**\*test*.dll as my "Test Sources spec".

How to setup the target output path of a given resource file in Visual Studio

In the main project of my VS Solution I have a Resources folder with some required external tools. When building and publishing the solution, I get a .\Resources* with all required files there.
So far so good.
However I have to move some files to the parent directory.
My first attempt was do so with the Post Build Events. It works and does move them the correct folder.
Nevertheless in the publish output they still appear in the Resources folder and I need them in the parent one :/
Is there any way to setup the target output path for resources in Visual Studio?
After some research and experimental, I solved my problem.
Still, here's what I learned in the process.
The first attempt was adding the file to the project root and mark it as a resource. After publishing it worked. But having those files in the project root its lame.
Since I needed some *.exe files compiled in another VS solution, added them as a project reference. Gave it a try and it passed the "Publish" test. But still.. not the best way to do it.
After that, with some scripting and a post-build event, I copied the required files to the correct folder. Works.. but after publishing, they don't appear in the package.
However, there is still a possibility with the Mage tool:
http://msdn.microsoft.com/en-us/library/acz3y3te.aspx
This lead to some promissing experiments, however they ended up helping me realize how limited the MS ClickOnce is, so I decided to try other tools.
Here's a good start to follow:
What alternatives are there to ClickOnce?
I had a similar situation once. I found it became more trouble than it was worth to customize output paths and such in Visual Studio, to the extent that I wanted.
I ended up letting Visual Studio do its own thing with regards to file/project structure, and wrote a post-build script to copy everything that was needed into a final, 'publish-ready' directory.
I then set the execution target in Visual Studio to the new location, so I could run/debug as normal, but with the new folder that was organized how I needed it. Careful, I think this is a user project setting; so other developers will need to do this on their machines too, if they so desire.
I do recall changing some output paths and such to make the post-build script more simple. But changing things like that can lead to annoyances when you add new projects to the solution; you might need to configure them to match. It's all a trade-off :)
Two ideas:
Maybe you could move your resources into another project - a project just for resources - and then set their Build Action to Content and Copy To Output to true. Then reference this new project and build the solution. (This may not work as you want, just an idea).
Why not make your resources embedded resources instead. Keep them all within the Resources\ directory and access them programatically?

Resources