We Keep Coding

What causes Microsoft.Practices.Unity assembly not to load?

I am running a project that had been running without issue for some time but recently started throwing an error stating,
"Could not load file or assembly 'Microsoft.Practices.Unity,
Version=2.1.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
or one of its dependencies. The system cannot find the file
specified."
I see that this assembly is for IoC/Dependency Injection support however I never explicitly added it to the solution; although I do see that it is in fact there.
When I check the version of the assembly it is showing the same version that is being referenced in the above error; so I cannot figure out why the file cannot be found by the project.
In effort of resolving the issue I've cleaned the solution, deleted my obj folder, rebuilt, removed and even reinstalled the assembly via nuget but the issue persists.
I've found somewhat similar issues reported here on SO but the proposed resolutions were either not applicable because it was not the same assembly reference as the one I'm having issue with OR it involved configuration of a XAML based application. This is ASP.NET.
The only other clue that I could find as to why I'm having the problem is that the targeted runtime framework of the assembly is v2.0.50727 and this application is .NET 4.5
Which would seem a reasonable explanation for the problem from my limited perspective except that the app was previously running without the problem.
I'd also mention that the assembly isn't explicitly being called from the block of code throwing the error; which is simply creating a web service client and calling a method.
long memberId = 1326728123;
ServiceClient sc = new ServiceClient("ServiceClientEndPoint");
var leadPackage = smc.GetLeadPackages(memberId);
So there could be other variables of this equation that may be attributing to the problem (e.g. Network blocking and etc)
I just wanted to make certain that I may not be missing something by running it past SO before wasting time going in the wrong direction for an answer.

Note that this could mean a number of things, including that one of the dependent assemblies of Microsoft.Practices.Unity could be loaded.
The first place searched is the GAC, if you are building and running on the same machine, this probably won't cause a problem because the runtime will also find the same library but if you are deploying, the project will sometimes bind to the GAC library whereas the production server might not have it installed and it will fail to run. CopyLocal=true should fix that but if you are deploying, you should check that the library is copied into the bin directory.
Secondly, you should open Microsoft.Practices.Unity.dll using reflector or ilspy.exe and see what other dependencies it has (other than the System.* libraries) since any other ones will need the same treatment as Microsoft.Practices.Unity i.e. adding to the project and copy local set to true.

How to bundle a required DLL with a solution in Visual C# (Express, 2010)

I have an application written in C# which interfaces with some custom hardware using a vendor supplied .Net assembly. The .Net assembly in turn loads another DLL at run time. I can add the vendor supplied assembly to my project but when I run it, the vendor assembly complains that it can't load the required DLL. I can work around this for the moment by copying the DLL to the bin\Debug and bin\Release folder.
The problem is that I will need to distribute this application to clients at some point and they will not have this DLL in place. I can't see how I can make the solution require it; I can't add it as a reference since I get the error "A reference to foo.dll could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component."
I can't convert the DLL to a .Net assembly using TlbExp, it gives an error "The module was expected to contain an assembly manifest."
I thought if I published the application via "click once" that I could declare the dependency there but I don't see any way for this either. I also tried adding it as a file resource but this didn't seem to help.
I can see other questions on SO relating to how to invoke functionality in an external DLL but in this case, I just need a way to bundle the DLL with the project.
Thanks.

Indicates that the attributed method is exposed by an unmanaged dynamic-link library (DLL)
The DllImportAttribute attribute provides the information needed to call a function exported from an unmanaged DLL. As a minimum requirement, you must supply the name of the DLL containing the entry point.
For further reference go here
Link to Review

You could add the dll as a resource, write it out as a byte[] to a file on loading, and do an Assembly.Load() at runtime for deployment.
You might have to use an AppDomain.AssemblyResolve Event to make sure the assembly resolves in case of multiple versions.

you could add both (all) of the dlls in your project as references and mark them as "copy local". That should do it unless the first DLL expects the second DLL in a specific place.

Getting rid of Assembly with TagPrefix in .NET 3.5

I had to change my .NET 3.5 web site to a web project, so I needed to remove the App_Code folder but found that I still have these:
<%# Register Assembly="App_Code" Namespace="MyNamespace" TagPrefix="pf" %>
What's the simplest way to get rid of this? I tried renaming the assembly to the projectName.dll but that crashes.
Any ideas?

You might use this:
<%# Register Assembly="YourAssemblyName" Namespace="YourNewNamespace" TagPrefix="pf" %>
Regarding a Web Application Microsoft says:
All code-behind class files and stand-alone class files in the project are compiled into a single assembly, which is placed in the Bin folder. Because this is a single assembly, you can specify attributes such as assembly name and version, as well as the location of the output assembly.
So now you should have a unique assembly.

The original idea behind app_code was that code could be dropped in at any time and consumed by the web application. This is a problem because it doesn't really show up in a normal project. So to convert you need to take the code found in app_code and convert into one or more class libraries and include in your web project. when this build's correctly, change the register assembly tags to point at the new .dll file(s).

How does classic asp access .NET dlls that are referenced by a COM-Visible class?

I have a COM-visible dll "COMInterface.dll" which is deployed into an existing application's folder. I have created a test harness that has verified the functionality of this dll.
However, when I try to use classic asp to call one of this dll's methods I get a message like the following:
MyCompany.MyProject.COMInterface (0x80070002)
Could not load file or assembly 'MyCompany.Framework, Version=2.6.4202.14897, >Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
My "COMInterface.dll" references a number of other dlls such as my company's standard framework, logging classes etc. "Framework" is one of these such dlls.
Where will the asp page be looking for these dlls? I am guessing that my harness worked because it was being run from the program folder whereas the asp page is within an IIS web site.
Do I need to use GAC registration here? I'm hoping not as there would be quite a few dlls I would need to deploy there and I am hoping to extend the application without having to impact the core installation on users' machines.
Thanks in advance of your questions and suggestions.
[EDIT]
I should point out that the object can be created fine. It's the location of the referenced dlls that are causing the problem.

When you use Regasm to register the dll you need to use the /Codebase switch to ensure the dll can be found.

As a general answer, you can use Fusion Log Viewer to determine what paths have been searched by the assembly binder.
See http://msdn.microsoft.com/en-us/library/e74a18c4.aspx for information on this tool.
Fusion Log Viewer will list all the paths probed by the binder. If you put your assembly into any of these paths it will be found. Whether any of these paths will be suitable for your scenario I'm not so sure.

Missing System.Windows

I have a rather large solution with some Silverlight and WPF projects inside it, as well as some class libraries and other things.
One of the project is a class library that references a SilverLight application which references System.Windows
But at runtime, I get the error:
{"Could not load file or assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified.":"System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e"}
I looked in the GAC (C:\Windows\assembly) and couldnt see it in there...
Whats happening here?
The reference is to: c:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\System.Windows.dll which DOES exist.

Sounds to me like your WPF app is loading a class library that references a Silverlight assembly. That cannot work, cats and dogs. If an assembly is referenced by both a WPF and a Silverlight app then it has to be compiled twice with different framework assembly references. That takes two projects. Keeping the WPF and the Silverlight stuff separate in different solutions is the best way to keep out of trouble.

I've seen similar errors in two cases that might apply here:
When an assembly I reference required an assemble I have not referenced . . . in this case that would mean System.Windows is using something else you need to add a reference too.
The more interesting case is when VS2010 auto selected ".Net Framework 4 Client Profile" for me when I actually needed ".Net Framework 4" (no "client profile"). Select the project properties and see what your setting is.
Frank
Per you request additional instructions:
Open Solution in VS2010, right click the project in question (not the solution line) and select "properties" from the bottom. In the resulting GUI, select the "Application" tab and make sure "Target Framework" does not have "client profile" in the name . . . that is should be ".NET Framework 4" not ".NET Framework 4 Client Profile".

I have not found this solution anywhere else, but stumbled upon it as a trial-and-error-by-fire...
The error message was a bit misleading in my situation. The tip off was that it wasn't really the "System.Windows" assembly itself, but one of the dependant assemblies.
What you may want to do is to check your GAC and see if one of these assemblies are in it:
System.Windows
System.Windows.Controls
System.Windows.Controls.Toolkit
System.Windows.Controls.Layout.Toolkit
Try removing them from just the GAC, then do your rebuild. If it doesn't work, just open two windows explorer windows and copy them back from either the c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\System.Windows.dll folder or the folder for your Silverlight Toolkit and you'll be back to where you started from.
Here's what I suspect is happening:
The Visual Studio 2010 compiler is getting confused about where to get those referenced assemblies when doing the build because the GAC assemblies always takes precedence over another copy of an assembly (even the reference assembly folder that VS2010 uses). So even though the assembly is technically correct with the same ID key and everything there's something with the VS2010 compiler that can't determine which library to use for building and it will refuse to complete the build.

mmmm sometimes you put your classes in different project for example you can create a project for viewmodels , if is this the case then you need to reference PresentationCore.dll , this is the dll that give you access to System.windows so you can use ICommand for command bindings