Having upgraded a large project from VS2008 to VS2013, a large number of unit tests are now failing because the associated data file cannot be found. The original DataSource attributes were created by the test connection string wizard that VS2008 provided, but this is no longer available in VS2013 Pro. The data files are definitely there, in exactly the same place in the solution, and all have the properties set to Copy Always. I suspect that the required arguments to the DataSource attribute have subtly changed but the MSDN documentation offers little help in this respect.
The error is:
Result Message: The unit test adapter failed to connect to the data
source or to read the data. For more information on troubleshooting
this error, see "Troubleshooting Data-Driven Unit Tests"
(http://go.microsoft.com/fwlink/?LinkId=62412) in the MSDN Library.
Error details: The Microsoft Jet database engine could not find the
object 'MatrixSampleResultGrid_ExcludeHiddenResults.csv'. Make sure
the object exists and that you spell its name and the path name
correctly.
Previously this error has always been reported because the data file has been moved or renamed without the attribute being updated, but that is definitely not the case here.
This is a typical current DataSource attribute definition:
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "|DataDirectory|\\MatrixSampleResultGrid_ExcludeHiddenResults.csv", "MatrixSampleResultGrid_ExcludeHiddenResults#csv", DataAccessMethod.Sequential)]
In the VS solution (ie on disk) the actual path to the datafile is
[theProjectRootFolder]\TestData\MatrixSampleResultGrid_ExcludeHiddenResults.csv
The test results are published to
[theProjectRootFolder]\TestResults\[testrun_datetimestamp]\In and ...\Out
although I notice that none of the data files have been copied to the In or Out folders. Is that significant?
With VS2008 these attributes have worked unchanged every day for years, so I can only conclude that for VS2013 the data is no longer appropriate, but what has changed? Without that wizard I can't even reconstruct the attribute so I am at a loss.
Also, I don't know what location "|DataDirectory|" represents in the context of a test run.
Can anyone help?
TIA.
I have figured out the solution to why all our VS2008 data-driven tests fail to find their data files in VS2013. Having spent hours reading all the MSDN documentation I could find on unit testing and TDD in VS with absolutely no illumination (useless!), I am posting the solution here to save others in a similar situation from all the pain:
The VS2013 test framework seems to have different rules on where to look for the data file (different to VS2008, that is). Either we were inadvertently employing an ‘undocumented feature’ in VS2008 which no longer works, or MS have simply changed it. I don’t know which, but it has changed.
However the fix is simple once you have tumbled to the cause. Assuming the data file is in a subfolder of the test project folder (ex [projectfolder]\TestData) , the old VS2008 test attributes:
(ex)
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "|DataDirectory|\\MyDataFile.csv", " MyDataFile#csv", DataAccessMethod.Sequential)][DeploymentItem("Test Projects\\Project1Tests\\TestData\\MyDataFile.csv"), TestMethod()]
need to be amended to
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "MyDataFile.csv", "MyDataFile#csv", DataAccessMethod.Sequential), DeploymentItem("TestData\\MyDataFile.csv"), TestMethod]
The changes are
The second DataSource argument is just the filename (not a relative path), and
The DeploymentItem argument is a path relative to the project folder that contains the tests.
Also (this has been documented elsewhere on this forum)
The datafile properties must be set to BuildAction=none (or the default blank), Copy To Output Directory=Copy Always.
and you have to have a TestSettings configuration in the solution with Deployment checked on.
Do all that and the old VS2008 data driven tests will magically all start finding their datafiles.
I'm evaluating TFS Build 2013 for use in a corporate environment.
TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.
I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.
I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".
So a bit of back of background on how we store and use references:
We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).
Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\References\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.
So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.
Crucially (it would seem) the first line reads:
For SearchPath "{HintPathFromItem}".
Considered "..\References\XYZ.dll", but it didn't exist.
Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.
So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\References" folder setup, or is there something else?
I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio
itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.
Thanks
UPDATE:
The build agent is configured as follows:
Build Agent- working directory:
D:\BuildAgent\$(BuildAgentId)\$(BuildDefinitionPath)
The build definition "Source Settings" have the (I assume) default values of:
Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)
Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:
The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:
D:\BuildAgent\1\ClientName\SolutionName\src\Dev\Evolution\Source\SolutionName.Solution\References
If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\path\to\Solution.sln" then it builds successfully with no warnings or errors.
Well it turns out this wasn't a fault with TFS at all...
The problematic DLL, although present in the References folder, was not actually checked into TFS.
Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.
So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.
I've got two files in my build named State.cpp. When I generate the VS project with the Introjucer and try to compile, both of those files clash to the same object file and I get the warning:
Warning 1 warning MSB8027: Two or more files with the name of
State.cpp will produce outputs to the same location. This can lead to
an incorrect build result. The files involved are
......\audio\State.cpp, ......\sg\State.cpp.
and then various link errors.
I can correct this easily enough within VS by modifying the Object File Name property on the VS project. However, when I regenerate the project with the Introjucer, that setting gets blown away.
Is there a setting I can use in the Inrojucer's config pages to prevent the clashes?
Just to close this one down...
There isn't. Rename the file for now.
We discussed this on the forum. I think Jules is up for making a change to the Introjucer to fix this - but it hasn't been done yet.
http://www.juce.com/forum/topic/msvc-build-consistency
http://www.juce.com/forum/topic/introjucer/visual-studio-2013-object-file-clashes
I have a problem when migrating a solution from VS2008 to VS2010. The problem is that the managed resources are not found in some cases in runtime, since they are not embedded with the correct name:
"Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "Production.ViewDocument.resources" was correctly embedded or linked into assembly "RSProcess" at compile time, or that all the satellite assemblies required are loadable and fully signed."
System.Resources.MissingManifestResourceException is typically thrown InitializeComponent in a call to ApplyResources on a resource that is created passing the type id. In my case the namespace is Production and the class name is ViewDocument. However, the resource generated (from the ViewDocument.resx) is named from the folder structure where the resx file is, in this case Production.folder1.folder2.ViewDocument.resources.
In VS2008 you could override the (default) logical name in in a setting on the .resx file, Managed Resources/General/Resource Logical Name. In VS2010 I cannot get this to work - it simply ignores this setting completly! Is there any ohter way of solving this?
One last resort would be to remove the current folder structure and move all files to the root project folder, but this seems to be quite a lot of work in my case.
Any suggestions?
I have found an answer to my own question!
A couple of things has changed in VS2010 that confused me. First, in VS2008 the names of the .resource files were affected by the project setting 'Resource Logical Name', in VS2010 the files are always named according to the root namespace of the project and the folder structure (extended namespace). Second, when migrating, these settings were blanked out, perhaps because we had used a macro $(InputFile) that has been replaced by %(Filename).
To fix this problem, I defined 'Resource Logical Name' on the project level (or you could use project property pages) to $(RootNamespace).%(Filename).resources. Note that the .resource files still get the extended names (defined by in which folder they reside). However, if you check the log file from MSBuild you can see that the logical name appears in the /ASSEMBLYRESOURCE swich to the linker in addition to the resource file name! After rebuilding, the ComponentResourceManager will now find the resources in 'InitializeComponent' using the type for the view, Rootnamespace.filename in this case. Also note that this assumes that your view classes are placed in files with the same name as the class!
In a team project I'm working on, setting a breakpoint in a file (say IdeasController.cs) will lead to erratic debugger behaviour if there's another file with the same name in the solution. I've reproduced the problem on several developers' workstations.
Example
I set a breakpoint in IdeasController.cs in our Web API:
Another file called IdeasController.cs exists in our separate MVC 4 web project. In the screenshot below, the debugger shows the Api->IdeasController source code, but the line highlight matches the code structure of Web->IdeasController. The breakpoint is duplicated, with one of them in the middle of a comment block.
The Breakpoint window shows the breakpoint in both files simultaneously:
On some workstations the debugger steps through the correct lines (regardless of the line highlight); on others it cheerfully steps through irrelevant lines (including comments and whitespace). I'm guessing this depends on which source file it chooses to display.
What I've tried
I've trawled the Internet. This kind of problem seems to occur when there's a mismatch between the debug file (*.pdb), the source file, and the compiled code. There are a lot of possible causes: duplicate file names (which can confuse the debugger[5]), outdated project build files, invalid solution cache, or incorrect build configuration.
These are the solutions I've found and tried:
Checked my build configuration.
Made sure the project isn't built in release mode.
Made sure we don't have code optimization enabled.
Made sure the project's debug module was loaded correctly. (Started debugging the project and checked Debug > Windows > Modules. Both assemblies are listed, not optimized, and have a symbol status of "Symbols loaded".)
Reset the debugging metadata & Visual Studio cache.
Closed Visual Studio and deleted the solution cache file (*.suo).[1]
Deleted each project's build output (the bin and obj folders). (For future reference: open the solution folder in Windows Explorer and type this in the search box: "type:folder AND (name:=bin OR name:=obj)".
Deleted the assembly cache folder (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3).[2][3]
None of these had any effect. I can rename one of the files (without renaming the class) to temporarily work around the problem, but that's far from ideal.
Where I am now
Page 14 of my latest Google search. Suggestions would be much appreciated. :)
If no better alternatives exist, you could put the breakpoint in code:
System.Diagnostics.Debugger.Break();
Just don't forget to remove it afterwards...
I'm so glad I found this post, thought I was the only one and was going insane! I'm having the same problem in VS2012 with VB.Net and have tried everything the OP mentioned.
Unique naming of the files seems to be the only 100% fix that I've found. Disabling all breakpoints until the application has loaded and then re-enabling the breakpoints you need works most of the time. Breakpoints in Lambda functions can still give you issues.
I just had the exact same problem. What solved it for me was deleting the .suo files belonging to the solution that contained the affected project/source file.
I also deleted my local symbolcache but I don't think that had anything to do with it.
(My solution contains multiple projects, one file (DataAdapter.cs) in one project was affected by this (VisualStudio put my breakpoints in the pdb belonging to System.Data.DataAdapter). I opened the .csproj file directly and was able to correctly set the breakpoint.)
I had the same problem today. I was able to trace it back to the fact that I had forgotten to set the platform target to x86 while debugging. Unfortunately the others (x64 / Any CPU) can be problematic while debugging. At least VS 2008 doesn't like them. I guess this is yet another reason to stay away.
Some speculation... I think the debugger (while running a 64 bit app) somehow "steals" breakpoints away from a file in certain cases. For me it was because another assembly was loaded first which had the same file name. I was able to avoid the issue, even in 64 bit mode, if I first manually loaded the assembly with my breakpoints: Assembly.Load("MyAssemblyWithBreakpoints");
Hope this (my first stackoverflow contribution) helps.
Although renaming one of the files will work, I found that the simplest solution is to temporarily disable automatic loading of symbols for the "other" assembly.
Start the debugger and continue until you hit the erroneous breakpoint.
Find where the debugger actually set the breakpoint using the Call Stack window:
Right-click on the row with the yellow arrow and enable Show Module Names. (The row should also have the red breakpoint symbol on it.)
The assembly name is now visible on that row.
Find that assembly in the Modules window (Debug > Windows > Modules).
Right-click on the assembly and disable Always Load Automatically.
Stop the debugger.
Start debugging again.
By doing this, you're preventing the Visual Studio debugger from mapping the breakpoint to the wrong assembly. It will then load the symbols from the other [presumably] correct assembly first, therefore mapping the breakpoint to the correct assembly.
Why does this happen?
This seems to occur when two different symbol files (PDB files) — for two different assemblies — both reference a source file with the same name. Although the source files are completely different, the Visual Studio debuggger seems to get confused.
For example, imagine there are two different files both with the name IdeasController.cs. The first one compiles into assembly Api.dll, and the second one compiles into assembly Web.dll.
When the debugger loads symbols, it will either load Api.pdb or Web.pdb first. Let's say it loads Api.pdb first. Then even if you set a breakpoint in Web\IdeasController.cs, it will find a match for IdeasController.cs in Api.pdb. It then maps code from Web\IdeasController.cs to Api.dll. This won't map correctly, of course, and so you see all sorts of odd issues while debugging.
I just had this issue on Visual Studio 2017 (Version 15.9.7), were break points were skipped and the debugger just "jumped" over return statements etc.
After a while I noticed, that I've recently added a .runsettings file to the project - and it turned out, that in my case configuring the CodeCoverage data collector is causing this problem.
As soon as I removed this section:
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>
from the .runsettings file, it worked like a charm again.
I just backed up and deleted the file and then added back to the project, that solved the problem. I just whish i did it before going through the beforementioned list :)
You may also try to Clean and Rebuild (not Build) all projects.
I was hitting this issue in Visual Studio 2015.
I had a sub-folder with a DLL I wanted to save as Version1. It seems even after removing the reference to that DLL, and then adding a reference to another project studio pulled in the existing reference and went to the wrong source file. I removed that DLL in the sub-folder then Studio got the correct source.
I found a helpful link on [MSDN that shows how to clear prior associated source files in studio at this link][1].
Summary:
In the Solution Explorer, right click on the solution name (ex: Solution ‘TestApplication’) and select Properties This will bring up the Solution Property Pages dialog
Under Common Properties, select Debug Source Files
In the Search these paths for source code files (Visual Studio .NET 2003) / Directories containing source code (Visual Studio 2005) box, add, remove and/or reorder the directories as desired
Click the OK button
I was having the same issue. In my case both the projects had same port numbers. I was able to resolve it by changing the port number of the project whose file's breakpoints were not hitting.
My guess is that IIS Express was caching the pdb file from the second project since both files had the same name, and the projects had the same port number.
What worked for me (VS2017) was disabling this option in Tools --> Options... --> Debugging --> General: "Require sources files to exactly match the original version", which is enabled by default but I had it turned on.
That was not enough though, I also had to manually remove obj and bin folders for all projects in solution.
Delete all the .pdb files of the project where the break point is hitting wrongly. This will solve the issue.
It happened to me (in VS 2008) to have two child breakpoint with the same memory address and the same associated file.
Those breakpoints were spawned at a certain time during the running of the process.
I noticed that I had duplicated .dll files in my project folders, and resolved removing the duplicated .dll, while keeping only one .dll per name in the debugging folder structure. (As example in my case I had /bin/Example.dll and /bin/Plug-in/Example.dll both present under my debug folder structure).
I had a very similar problem. In my case the problem was a different target .net framework in one of the projects causing VS2017 to wrongly load a source file (with the same name) of another project, not the one being activated with
ObjectHandle handle = Activator.CreateInstance
Changing the project's target framework to be the same in all projects fixed it.
I had a similar issue with the breakpoint being set in another file with the same filename in a different project.
It was caused by the fact that the debugging was started for that other project, while it was not started for the project where I tried to set the breakpoint. The breakpoint creation worked correctly after doing the Debug > Start New Instance for the intended project.