I have problem with build in VS2010. I´m trying to develop small Prism, MVVM application.
I added new project "Toolbar" to my solution "MyApp" and during the build I get following error (propably project´s dll is not created for some reason):
Error 2 Could not load referenced assembly
"C:\net\projects\MyApp\MyApp.Modules.Toolbar\bin\Debug\MyApp.Modules.Toolbar.dll".
Caught a FileNotFoundException saying "Could not load file or assembly
'C:\net\projects\MyApp\MyApp.Modules.Toolbar\bin\Debug\MyApp.Modules.Toolbar.dll'
or one of its dependencies. The system cannot find the file
specified.".
C:\net\projects\MyApp\MyApp\ResGen MyApp
I´m quite new to VS2010 and C# so I really don´t know what happend, wheter project dll is missing because of some mistake in source code or why this can even happend? I also don´t know how to find such a mistake in source code, because VS shows up only the error mentioned above. Dependenies of the project should be ok i guess, file MyApp.Modules.Toolbar.dll really doesn´t exist in any folder on my hdd.
The problem was the bad class name defined in xaml of Toolbar project (UserControl x:Class="BAD CLASS HERE").
After many googles for a similar problem where I had at one time toyed with using open office in a .net project and then all my aspx pages had the blue squiggely line saying cli_uno couldn't be found which was referenced no where and in none of my project or lib files.
I deleted all the bin folders, a dll referencing it was hiding in one of them and making vs2010 freak out.
I realize this isn't the exact solution to the above but there isn't much out there for this error and it is a head scratcher and deleting all the bin folders worked for me so it's something to try.
You provide too litle information, so I'll ask some questions (and some possible fixes):
Is the file at the specified path to begin with?
If not, is there a project you need to build to create the dll?
If there is such project, does it build the .dll where yours is looking for it -- if not, you either need to copy it by hand or set up a post-build process to do the copy automatically after each build
If there is no such project, do you have the .dll itself somewhere. If yes, you need to copy it to the correct location.
If the .dll is at the correct location, is there some protection preventing the other project to access it?
Related
I found tons of posts asking about how to fix when Microsoft.SqlServer.Types.dll is missing, but I have the exact opposite issue -- it is in my output directory and I have no idea why.
The project in question references another global project within the solution, but I have checked the references and extensions for both projects -- nothing about Microsoft.SqlServer.Types. So, any idea as to why it would be considered a dependency when I rebuild the solution? I go to "Add Reference...", Extensions, and I can see "Microsoft.SqlServer.Types" in the list, NOT checked. How do I get rid of this reference?
Background: I just added reporting to my project and was using a data source (.xsd file) in my project. I have since switched to using simple class/object references as the data source so I deleted the XSD data source that used OLEDB to Foxpro DBF files. But I am thinking the Microsoft.SqlServer.Types reference got added at that time and now it won't go away.
The DLL (and regional folders for it) copy to my output directory because I am using the trick where all referenced DLLs get copied and then embedded into the application executable (so that I don't need to use ILMerge or deploy a bunch of DLLs -- the exe is standalone in that regard).
How do I find out where this reference is still sticking and get rid of it?
Never mind, it looks like Microsoft.SqlServer.Types is required by Microsoft.ReportViewer.Common. So, just adding reporting to my app brings in a lot of stuff... (well, not really that much, size-wise...)
A project that I've been working on for a long time without any problems suddenly started throwing errors such as
The type or namespace name 'xxx' does not exist in the namespace 'yyy' (are you missing an assembly reference)?
In this case, the namespaces were all core .Net libraries such as System.Data, Linq, and IO that I've been using without any problems.
I've worked through all of the issues in this question such as making sure all the projects in the workspace are using the same version of .Net for the Target Framework setting.
I removed all the libraries in question and re-added them but the problem persisted. I doubt they libraries themselves are corrupted as I reference them in other projects within the solution.
After rolling back through my work with TFS I managed to work out what I'd done that had created this error: I'd added a folder called "System" to my project and put a class file in it.
This is an easy issue to reproduce: create a project, add a folder called system to it (it will still compile at this point) and then create a .cs file in it, that's when all the fun errors will occur.
The problem stems from the name of the "System" folder which leads to any files created in it being under the namespace ".System".
I can understand why having a folder / namespace called "System" would cause problems now but I think it would help if Visual Studio warned when creating a folder / namespace of such a name to stop this problem happening in the first place. I've logged a bug with MS, at least having this logged might help any other people who have made the same mistake as me!
I had the same issue after my system shut down unexpectedly and even though VS tried to restore, the problem popped up.
I had two projects in my Solution Explorer. To solve this, I right-clicked the project that was associated with the error message and selected 'Build'.
After that, the issue was resolved.
Just to add that the problem was permanently solved after I added a reference to the 'project' from the other 'project'.
I renamed the namespace of the file I was referencing from myproject.shared.constants to myproject.SOMETHING.shared.constants
After that It suggested "use myproject.SOMETHING.shared.constants" as suggestion. I renamed it back to myproject.shared.constants and then it worked.
Try to Clean and Then Rebuild the dll file .I was experiencing the same problem tried different suggestions from internet but none of them work.But it will. In case you don't know how follow these steps:
open your dll project file.
2.click on solution Explorer Right click on Your Dll Project Name you will find Clean and Rebuild Option.
I am trying to compile the example project shown here for C#. It had to be converted to VS2010, but that worked fine. It builds, runs, but then dies when it tries to access a DLL function.
I made a series of images to show my steps. As you can see, the device I designed is attached and correctly configured, but I really don't think that has anything to do with the issue. Inside the Form1.cs file, the following comment explains how to use the DLL:
/*
PLEASE NOTE
You must add a reference to the FTChipIDNet.dll in order to use this sample
To do this:
1. Click on Solution explorer tab.
2. Right click the References tree.
3. Choose Add Reference option.
4. Browse to the FTChipIDNet.dll (as a personal preference I place this in my bin directory)
5. Click OK
*/
I followed the instructions shown above and the undefined reference to the namespace FTChipID was fixed. I also manually checked the Object Browser to be sure the GetNumDevices function exists and it does.
Clicking the button produces this error:
DLLNotFoundException was unhandled:
Unable to load DLL 'FTChipID.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at this line of code:
FTChipID.ChipID.GetNumDevices(ref numDevices);
Now, you may be thinking "the error says it needs FTChipID.dll, not FTChipIDNet.dll." I'm wondering the same thing. I have FTChipID.dll along with a .lib and .h file, but I don't know how to use them or where they need to be in order for this program to find them. I tried adding a reference to FTChipID.dll, but VS2010 said
A reference to ...\FTChipID.dll could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.
I don't know what that means either. Any ideas? Thanks in advance.
FTChipIDNet.dll is a wrapper for the FTChipID.dll, so you need to add the reference to your solution (as you did above) and then copy the FTChipID.dll to the bin folder there FTChipIDNet.dll will be located.
Both dll's should be located in your solution's bin folder to operate and should not be located in windows\system32.
I built the FTDI sample program "CSChipID" in VS2013 using a build to "Any CPU". The two DLL files "FTChipID.dll" and "FTChipIDNet.dll" were copied to the bin directory, but I continued to get errors when the first DLL function was called, "FTChipID.ChipID.GetNumDevices(ref numDevices);" The fix is change the build to "x86" as follows.
Build - Configuration Manager
Active Solution Platform - "x86"
Note: If "x86" is not available, select -New...- to select "x86".
It sounds like there are multiple .dll's: both FTChipIDNet.dll (the one you interface to), and FTChipID.dll (the one with the actual, non-COM, non-.Net functionality). You need both.
SUGGESTION: Copy both to your \windows\system32 directory
This must be a really stupid question, but I'm still very green when it comes to C#.
Anyway, I've got a DLL and I'm importing it with a line like this:
[DllImport(#"MyCoolDll")]
I've lifted this straight from the demo app provided by the vendor, but it keep complaining that it can't find the DLL. The actual error (from Visual Studio 2010) is like this:
Unable to load DLL 'MyCoolDll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
I've tried placing the compiled DLL in the bin/debug and bin/release folders. I've even tried copying it to system32, but nothing seems to work.
Any ideas?
Your DLL may have dependencies that also need to be loaded. Did you check for that?
I know you have to give the full file name. So
[DllImport(#"MyCoolDll.dll")]
It should work from the bin\debug or bin\release folders.
Update
This is where I learned how to import unmanaged dlls. If it was a test app that is working correctly, check it's bin\debug folder to see what is different from yours. Possibly an extra dll being referenced? Also check all the references within the sample app to make sure you are not missing any.
As far as I know you have to provide extension:
[DllImport(#"MyCoolDll.dll")]
I usually keep these dlls locally with the program binaries (so in bin\Debug for development)
The key for me was to look at the paths listed in the Visual Studio Build console output, to see where the binaries were being placed. Once I found that, I knew where to copy the unmanaged dll and it fixed the "Unable to load DLL" error.
I am getting an error back from a DLL saying it cannot create an instance of one of classes in my solution because it cannot find the assembly file.
If I am debugging a solution, do I need to put a copy of certain assembly files in other locations?
EDIT:
In my compiled solution all the DLLs (including the proprietary ones) all go in the app directory and it works fine. But I am trying to work out where the files should do in order to debug the solution.
Put the assembly in question in 1) the same directory, or 2) in the GAC, or 3) use AssemblyBinding to define the specific path that the .NET framework.
MSDN link: using AssemblyBinding to define the referenced assembly path
I think you have forgotten to add reference of the assembly to the project.
Add the reference, and try again.
Read more here -> http://msdn.microsoft.com/en-us/library/7314433t%28VS.80%29.aspx
If they are in your references list, try right-clicking the problem reference in the solution explorer and selecting "properties". There is one property called copy local. Make sure that is true. Then when you build, a copy of that dll will be in your bin folder.
You can add an event handler to AssemblyResolve to find out which library it tries to load. Some sample code and ideas can be get from this question.
Update
To find out, what is the best place for your project you should take a look into How the Runtime Locates Assemblies guide. Also to get a live view about where the framework searches for your needed dll you can use ProcessMonitor to see where it tries to catch it.