41

I just downloaded PoshConsole's source code and was trying to build the solution. I initially had two problem -

  1. the System.Interactivity.dll could not be resolved. I installed Blend 4 SDK and that issue was fixed.

  2. Unknown build error - Cannot resolve dependency to System.Windows

Right now, whenever I try to build the project, I get the following error in two projects in the solution and I haven't been able to find a solution after some googling around.

Cannot resolve dependency to assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.

gprasant
  • 15,589
  • 9
  • 43
  • 57
  • I had kinda the same error in a solution once. I needed to build it again sometimes even twice before the error was gone. Maybe it works? – Mixxiphoid Aug 31 '11 at 07:20
  • 3
    Maybe doing a `Build->Clean Solution` could help too. – George Duckett Aug 31 '11 at 07:23
  • Do you have Silverlight installed? It's hard to say, but I think that might be the problem.... which is strange, becase poshconsole doesn't seem to require Silverlight. – Miguel Madero Jan 27 '12 at 15:09

5 Answers5

64

I have received this error message for another (non-GAC, custom) assembly.

In my case, the situation was as follows:

  • assembly X contains class A
  • assembly Y contains class B, which inherits from A
  • assembly Z contains a data template for class B

Y referenced X, Z referenced Y.

The error message was pointing to the line in the data template in Z where B was referenced, and pointed out that X could not be loaded.

The solution was to have Z also reference X. Apparently, the compiler cannot resolve that transitive reference for loading the required assemblies on its own.

O. R. Mapper
  • 20,083
  • 9
  • 69
  • 114
  • 1
    Worked for me, too. But I don't understand it. Normally sssembly referencing is transitive, isn't it? – anhoppe Dec 07 '15 at 20:29
  • 3
    @anhoppe: Well, it depends, or at least things are not always as they seem intuitively. When you use a class *S* that *uses* another class *T*, you do not need to know about *T* (or reference its assembly). However, when *S* *inherits* from *T*, you are, so-to-speak, also using *T* yourself (even though you might just be handling *S*), and thus need to reference *T*'s assembly. – O. R. Mapper May 22 '17 at 11:08
  • This worked for me when the issue was a missing Microsoft.ServiceFabric.Services.Remoting after it was split out from Services. – Will Tartak May 27 '17 at 19:54
  • The answer works. It is a known bug and it is reported here: https://connect.microsoft.com/VisualStudio/feedback/details/390589/wpf-builderror-cannot-resolve-dependency-to-assembly-name-because-it-has-not-been-preloaded – Drake Jul 12 '17 at 15:06
18

That error generally means that you've added a reference to a Silverlight assembly within a WPF project - the two can't coexist.

See: Errors when referencing Silverlight class library from WPF application

Community
  • 1
  • 1
Chris Hines
  • 722
  • 6
  • 12
  • I am experiencing the same error (though for a custom assembly, not a default one from the GAC) without having changed anything about the references. – O. R. Mapper Apr 09 '14 at 11:46
  • EDIT - Never mind, looks like you answered your own comment below. Yes, that's a different, but tangentially related issue that you hit. – Chris Hines Apr 09 '14 at 17:25
  • Yes, I found the solution a bit later and thought I'd add it here, even though it may not have been the OP's original problem, future visitors who come here with the same error message may benefit from either one of our two responses. – O. R. Mapper Apr 09 '14 at 19:32
  • This was my issue. I was adding Silverlight dll to WPF project. – Ziggler Oct 11 '17 at 21:51
1

In your [projectName].csproj file, you can identify the non-resolvable dependency and remove it before add it again latter.

  • This was my error: v4.0.30319\Microsoft.WinFx.targets(268,9): error MC1000: Unknown build error, 'Cannot resolve dependency to assembly 'Microsoft.Data.Schema',...
  • in my .csproj file i identified the reference line with the key word 'Microsoft.Data.Schema'
  • i deleted the line and my project was able to be build again.

Hope it will help others

Gomez NL
  • 912
  • 9
  • 12
1

I would like to add some information in addition to O. R. Mapper's answer that suggests adding a reference to the assembly that is indicated by the compiler error.

I experienced the same problem while working on a WPF project. Considering the X,Y,Z relation presented in his answer, the problem happens when binding properties with types from X to a DataTemplate with DataType from Y. So, this doesn't happen for all assemblies that are referenced by Z, but rather those that only expose their specific types within Views. In my case, I was binding SelectedItem of a ComboBox to an enum property declared in X.

You can refactor these types to object and the problem goes away if you really want to preserve references as they should, especially if you use MVVM. Furthermore, the problem goes away by itself when you properly wrap Model types into ViewModel ones, because that generates explicit code that helps Visual Studio figure out required assemblies.

Hope this helps.

MatrixRonny
  • 437
  • 3
  • 11
1

I'm going to toss in and answer on this old question, in-case someone runs into the same issue.

I was recently working on a legacy program and had this error. The solution was not readily apparent.

Issue

One of the NuGet packages referenced was created for a bunch of internal libraries and stored on the internal NuGet repository.

The applications compiled fine on VS2013, due to all the NuGet references having in the Project files, directly to the libraries.

When these references were changed to (Does not support HintPath), many of these NuGet packages were not created according to nuspec. There was no lib folder.

The packages were remade to follow the spec, however several of the packages had old Silverlight libraries included in them. These libraries were causing the error.

Solution

Following nuspec, the lib folder had sub-folders created: net45 and sl4. .NET4.5 and Silverlight4.0 respectively.

When the packages were replaced with the new ones, the builds worked fine. Regardless of Project file version.

TL;DR

Old nupkg structure:

Package.1.0.0.nupkg
   - Library.Net40.dll
   - Library.Sl4.dll

New nupkg structure:

Package.1.0.1.nupkg
    - lib
        - net45
            - Library.dll
        - sl4.0
            - Library.dll
Victor Procure
  • 886
  • 1
  • 6
  • 17