I had to rebuild the Krypton.Toolkit.dll from it's source in order to remove a license error message on runtime. In the references I have removed and replaced the old Krypton assemblies with the ones from source.
I am now getting the error: (and a related cast type error)
Could not load file or assembly 'ComponentFactory.Krypton.Toolkit, Version=4.0.0.0, Culture=neutral, PublicKeyToken=a87e673e9ecb6e8e'
I understand the error message. Although the my new reference has the same name it does not have a strong name at all, so there is no PublicKeyToken.
What I don't understand is why it's still looking for the old PublicKeyToken when the reference is being replaced completely? This DLL is not in the GAC.
At first these DLLs with matching PKT where referenced in my main projects .csproj file. I gave my two assemblies a strong name and replaced the old references.
I have then cleaned and rebuilt the project and the new strong name has been replaced in the csproj file. However Visual Studio is still looking for a87e673e9ecb6e8e in the aforementioned project, as shown in the error window.
Sorted.
A reference was referencing the same 3rd party DLL as my project and they where conflicting.
Something in your solution seems to still hold a reference to the strong-named version.
You can open your .csproj (or I think .vbproj if you're doing VB) and look for that reference in your favorite text editor. Look for a line similar to:
<Reference Include="ComponentFactory.Krypton.Toolkit, Version=4.0.0.0, Culture=neutral, PublicKeyToken=a87e673e9ecb6e8e, processorArchitecture=MSIL">
</Reference>
Searching for the PublicKeyToken is probably sufficient.
If you find it, you will know which project still references the strong named version.
You may see a sub node like
<Reference ... >
<HintPath>..\SomePath\ComponentFactory.Krypton.Toolkit.dll</HintPath>
</Reference>
directing the linker to look in a specific path to resolve the reference.
You can manually edit the project file (back it up first), or use that knowledge to update the reference through VS if you're more comfortable with that.
UPDATE
If it turns out (as it did in this case) that the issue is with a referenced DLL that in turn references the other Krypton version, a good tool for diagnosing the issue is the Fusion Log Viewer
http://msdn.microsoft.com/en-us/library/e74a18c4.aspx
Note that Fusion Log Viewer must run as Administrator. If not, it will not show any results but will otherwise not complain.
Related
I am new to windows desktop application development.
I have created an application using visual - studio 2010 in which I have used one form for data entry. One form with report viewer control and a report(.rdlc) file which report is drawn.
My problem is that I want to make my application compatible for dot net framework 3.5. To do that, I have changed the target framework to 3.5 from the 'Advanced Compile Options...' from the project properties. But I am getting the error when I run the application after changing the target framework to 3.5 is :
Could not load file or assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Line 123, position 5. C:\Users\Amir\Desktop\Bill_System\Bill_System\Bill_System\My Project\Resources.resx Billing_System
How to tackle this error?
Please help. Thanks in advance.
It is a ratty problem with resources, as you can tell from the exception message, they also take a dependency on the framework version. Which is not changed by just changing the target version of your project.
Open the Resources.resx file in a text editor, Notepad will do. Search for "4.0.0.0" and change that to "2.0.0.0". That might not fix the problem, some resources are binary serialized and embedded as a base64 encoded string in the .resx file. You'll easily recognize them as a long string. You'll need to fix those with the Visual Studio resource editor, remove them and add them back.
You are referencing the System.Drawing assembly for the framework 4.0 (as you can read from the error) and not for the 3.5
You have to locate your System.Drawing reference and change it to 3.5.
The easiest way is to:
Open you Project
Go to Solution Explorer
Expand the Reference group
Delete the System.Drawing reference
Right click on the Reference group
Add Reference
On the ".NET" tab, search for System.Drawing to add the right reference
You got the following error:
"Could not load file or assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Line 123, position 5."
This error is occur due to incorrect path to the .dll of system.drawing assembly,the following 2nd line surely work for you.
OW please find the path in your system.
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Drawing.dll" related to your system
[Void][System.Reflection.Assembly]::LoadFile("C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Drawing.dll")
I have an issue where all my xaml views are saying there is a bad reference to System.Windows.dll. I ran ProcMon and realized it was looking for the dll's in the GAC. I started a new project, and it's looking for the dll's in the right spot (the Windows Phone 7 Referenced Assemblies folder).
All of my other projects are referencing fine (but this is the only one with views in this solution, other views work fine in other solutions). I'm pretty sure it's something to do with VS2010's assembly cache, or possibly SxS, but I can't figure it out.
Anyone have an idea? I don't want to GAC the libs, since that'll bring up other errors, I just want it restored to the way it was.
Here's the error I see in code for all my xaml pages.
Warning 1 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. C:\Users\myUser\Desktop\MySln\MyApp\App.xaml 1 1
Thanks!
You can just expand the References folder in your project and remove the defunct reference and add the right one?!
I'm creating a VS2010 extension (let's call it MyExtension). The UI for this extension is in a different assembly (MyExtension.UI), the extension project only contains boilerplate code to call the UI from the menu command.
MyExtension.UI contains localized resources (e.g. fr\MyExtensions.UI.resources.dll), but the VSIX package doesn't include these resources (although they are present in the bin\Debug directory).
How should I tell VS to include these resources in the VSIX package? I looked in the .vsixmanifest designer, but I can't find the appropriate option...
This is actually a bug that will be addressed in a future release. Fortunately, there is a simple workaround:
Select the Project Reference node to 'MyExtension.UI' in Solution Explorer and view the Properties (F4)
Change the value for "Output Groups Included in VSIX" to the following: BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;GetCopyToOutputDirectoryItems;SatelliteDllsProjectOutputGroup
#JohnField - I ran into the same error - "Could not determine the Full Name of the Assembly at '...'" - and wanted to list the fix here, in case anyone else runs into the same problem.
My issue was that I had both a ProjectReference to the referenced assembly AND I listed the Assembly as an Asset in my .vsixmanifest file. When you add a 'Copy To Output Directory' item to the referenced assembly, the VS SDK gets confused because it thinks the Assembly Asset you added was only for the Assembly. It sees the extra CopyToOutputDirectory item, and thinks it is an assembly and tries to load it.
The fix was to remove the Assembly as an Asset in the .vsixmanifest. This is not needed because the project is already being referenced, which includes the assembly in the resulting .vsix. Actually, the poorly name AssetType “Microsoft.VisualStudio.Assembly” is actually for template wizards.
Trying to follow this tutorial, under the section "Initializing the Project Factory" I've added EnvDTE to my project, but now I get this error:
An assembly with the same identity 'EnvDTE80, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' has already been imported. Try removing one of the duplicate references.
Even if I remove all the references to it, I still get it. It must be somewhere in the project base or something? What's creating two+ references to it?
Resolved this particular error by unloading the project, editing the .csproj xml file and removing the reference to EnvDTE in there.
In my project file, I have the following entry:
<Reference Include="Microsoft.Practices.Unity, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\..\..\Libraries\Microsoft.Practices.Unity.dll</HintPath>
</Reference>
which in absolute terms translates to:
C:\dev\LUT600 2.1.1\OCC600\Libraries
Somehow, when I try to compile the project, Visual Studio loads a reference from a totally different path:
/reference:"C:\Program Files\Microsoft Enterprise Library 4.1 - October 2008\Bin\Microsoft.Practices.Unity.dll.
How it resolves to this location is a complete mystery as this DLL is not referenced anywhere in this project.
I have set Specific Verion to true but it still resolves the reference from this location.
Any ideas?
TIA.
Klaus
It may be that the reference does not have the same version number as the assembly in that particular location, so it starts searching elsewhere to find a "better" match.
Rather than just taking the file you specified, VS always uses a probe path to try to find referenced assemblies. This often provides a random "pick anything with the same name" effect. On our build server I once found 996 copies of an assembly. 995 were the same, correct version, and one was the wrong version. And one day our build stopped working when for no apparent reason it suddenly decided to use the single wrong copy!
Try deleting and recreating the reference. That often helps.
In the worst case scenario, delete all copies of that assembly from your PC, except the version you wish to link to. (if possible without destorying anything you hold dear)
You most likely added the reference from the GAC(Global Assembly Cache). The long list of references that take a while to load are references from the GAC. Try removing your reference, and re-adding it by browsing to that assembly in the Add References dialog.
It could be finding the dll in the Search Path before it evaluates the HintPath. As mentioned in this post, there are two places that are searched before HintPath.
Files from the current project – indicated by {CandidateAssemblyFiles}.
$(ReferencePath) property that comes from .user/targets file.