0

I'm working in a team that has created a solution. In the solution we have 4 projects (data access, business logic and unit tests and common things).

  • BL references DA and CT
  • CT references DA
  • UT references BL and CT

Now whenever I rebuild it brings no errors. On my collegues PC it works without a hitch but on my PC whenever I try to run an unit test I get the following error (translated manually into english so any typos are my fault while writing this question):

{"The file or assembly \"MyWorkspaceName.MySolutionname.CT, version=0.2.0.0, Culture=neutral, PublicKeyToken=null\" or a reference of it was not found. The system cannot find the given file.":"MyWorkspaceName.MySolutionname.CT, version=0.2.0.0, Culture=neutral, PublicKeyToken=null"}

As that version and name exists (it is the common things part I manually checked if it exists) and I also checked the refernces inside of the CT if they are correct.....I'm not sure what could be a possible reason for it not working for me (but working on my collegues PC).

Thus my question would be: What could be possible reasons for that error message?

Update: CT is now found but when I try to access the DA from BL it says the same error as before just with DA instead of the CT (ran from the UT part).

When I run the SAME methods from a console application project created within the same solution, they work without throwing any error.

Thomas
  • 2,886
  • 3
  • 34
  • 78
  • This is not a solution to your problem. However, your CT shouldn't ideally refer DA rather it should be other way around. Ie DA should refer CT – S.N Jan 02 '15 at 09:07
  • Have you tried to build the CT separately then build entire solution? – Hamlet Hakobyan Jan 02 '15 at 09:10
  • @Nair the CT needs to reference the DA as the DA only consists of the entity framework (and a reference to the database). the CT needs to access the tables and is itself used by the BL and all other future projects. (under normal circumstances you are right it would be easier the other way round, sadly the naming is a bit bad for the projects) – Thomas Jan 02 '15 at 09:12
  • 1
    For problems like this, I always use the Fusion viewer http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx to diagnose the cause. – Polyfun Jan 02 '15 at 09:13
  • @HamletHakobyan If you mean rebuild the solution then clean and build the CT project yes tried that already (also the version where I after that built the whole solution again) – Thomas Jan 02 '15 at 09:18
  • No, I mean clean > build CT > build solution. – Hamlet Hakobyan Jan 02 '15 at 09:20
  • @HamletHakobyan tried but same effect. – Thomas Jan 02 '15 at 09:43
  • @ShellShock I used that tool (would be nice to be able to set it to english instead of my mother language as the windows are only sized for english and not resizeable :/ ) and it has some troubles with: C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 12.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\ does that ring a bell there ? (else I will translate the error message to english and post it into the question in a bit) – Thomas Jan 02 '15 at 09:45
  • @Thomas: In the viewer, click Settings, click "Log bind failures to disk", tick "Enable custom log path", enter a custom log path. Cilck OK. Click Delete All to delete all entries. Shutdown all processes associated with your application; shutdown and restart VS. Reproduce the error. In fusion viewer, click Refresh. Select suspect lines in the list and click View log to see more details (displayed as HTML). – Polyfun Jan 02 '15 at 09:53
  • @ShellShock tnx now I got an error entry with the CT. it says that it doesnt finde the CT.dll in the debug folder of the unit test project. But when I looked I found it there (tried the whole link it showed in the log). Log message was taht it tried the.DLL and also the .EXe and "All probing URLs attempted and failed." – Thomas Jan 02 '15 at 10:50
  • Also check that any dependencies of the CT.dll (and dependencies of the dependencies etc) are also in the debug folder. – Polyfun Jan 02 '15 at 10:53
  • didnt find any references it has that would be strange or nonexistent – Thomas Jan 02 '15 at 12:01
  • Have you checked there are enough permissions for the user running the tests to access that DLL in particular? – Jcl Jan 05 '15 at 09:09
  • Sometime you get this error when the reference path for the dll is bin\x86\debug and you're looking at bin\debug., or verse visa – Bayeni Jan 06 '15 at 10:50
  • @Thomas, can you show this reference in .csproj file? I mean raw xml. – Alex Erygin Jan 08 '15 at 20:51
  • @Thomas Are you running this off a network drive? – Jonathan Jan 12 '15 at 06:31
  • @JonathanDahan yes in contrast to my collegues I'm having the project files stored on a network drive (on one reserved just for me) – Thomas Jan 12 '15 at 08:49
  • @Thomas That's the problem then. See this previous stackoverflow http://stackoverflow.com/questions/159627/keeping-visual-studio-projects-on-a-network-drive – Jonathan Jan 12 '15 at 12:56
  • @JonathanDahan hmmmmm from what I read there they had mostly permission problems if I'm not mistaken? (tried out a few of those ideas there but didn't see the properties where they should be according to those docs given there) – Thomas Jan 12 '15 at 13:46

4 Answers4

2

There are three possibilities,

  1. Different CPU architectures, if your colleague's PC is x64 and yours is x86 then DLL reference setup in projects might differ and that could give this error.
  2. Different folder structures.
  3. Different third party references, see the details below.

Are you sure you have installed every third party tools/libraries that are there on your colleague's PC?

Most probably third party references should be added as NuGet packages but if your project references third party assembly which in turn references another assembly installed via some installer and which is absent on your machine, you may get similar error. I had similar problems and some native libraries do not show up in error as dependencies unless you turn on assembly log and investigate.

Akash Kava
  • 39,066
  • 20
  • 121
  • 167
  • It's a pain that the dynamic loader throws a very generic error if it can't correctly load the dll. There are many causes for a dll not to be loaded properly but you will get most of the time this kind of generic error. Also, although I doubt it's the problem here, I've seen case of some projects/binaries referencing the wrong framework. – John-Philip Jan 12 '15 at 08:57
  • What do you mean with different folder structures? (where we store them? or in the project?). Else third party references checked but didn't have any (we also checked the addons themselves for versions). Architectures are also the same on the pcs – Thomas Jan 12 '15 at 09:17
  • @Thomas, you may have all project files under d drive and your colleague may have it under e drive or something else. Did you check add/remove programs or uninstall a program? may be some third party tool is installed and is missing on your machine. – Akash Kava Jan 12 '15 at 11:19
  • Third party tools we have all the same (we have a departmentwide decision there which 3rd party tools we shall use. Addons I also checked with them. Same tools installed on all 3 laptops). Drives: We have different drives each (maindifference being that I store all my files a the network drive for backup reasons while my collegues store the whole project on local drives [they mostly in the default folders visual studio uses for project files]) – Thomas Jan 12 '15 at 12:14
0

Did you try to delete /obj and /bin folder before rebuilding? Sometimes there are old assembly reference caches which mess the build process.

Here is a PowerShell script for recursive erase of /bin and /obj folders. Just run it in the main solution folder.

Get-ChildItem .\ -include bin,obj -Recurse | foreach ($_) { remove-item $_.fullname -Force -Recurse }

Another possible problem that I have encountered is when there is a difference between assemblies installed in the GAC and locally downloaded NuGet packages. - Your VS gets the DLL from GAC but on your team mates computers the DLL comes from NuGet and it is different version.

To get the assembly binding information in VS : Tools -> Options -> Projects And Solutions -> Build And Run -> MS Build project build output verbosity -> Set to Diagnostic and when you build Copy-Paste the diagnostic info into notepad++ and search for 'error' and 'conflict' then resolve.

Ognyan Dimitrov
  • 6,026
  • 1
  • 48
  • 70
0

Usually if I can't solve such issues in a meaningful amount of time I go for help to Process Monitor

In your case I would add a not too restrictive filter such as: Path contains .dll and look for failure results during application launch. This might reveal what actual dll files could not be found and places were they were looked for.

mdonatas
  • 1,770
  • 2
  • 15
  • 15
0

Visual Studio works on a trust system, meaning you have to explicitly trust network drives. have you tried to copy the project to your local hard drive to see if it works?

Here is the article from microsoft on how to change the trusts using the CasPool.exe tool.

Caspol.exe (Code Access Security Policy Tool)

Just a few notes about this so you don't miss anything. There is different trusts for both 32-bit and 64-bit applications, so make sure you apply the trust to both to avoid any issues.

Before you go through the trouble of this tool, I would highly recommend that you copy to your local hard drive first and see if that is indeed the problem.

Jonathan
  • 2,778
  • 13
  • 23
  • Seems like it was exactly that. The local drive test was successfull with me being able to run the unit tests there without a problem! Currently reading through caspol to find out which parameters I need to set. I'll accept the answer as soon as I find out the exact parameters, but will give the bounty already as the trust thing was the issue in the end (would have never gotten THAT idea myself that that is possible) – Thomas Jan 13 '15 at 07:46