I have a problem when referencing a DLL.
I do everything correctly:
1.The DLL is built with no errors
2.I add it as a reference in my other solution
However the system doesn't recognize it and I get the folowing error message:
"Type or namespace could not be found.Are you missing an assembly reference?"
I read on various forums and adjusted the .NET version of the DLL to match the .NET 4 on my project.I tried all versions 4/4-Client Profile/4.5 and none of them fixed the problem.The DLL,I checked with .NET Reflector and everything is there and working as it's supposed to.
Can you help me with this issue?
Related
I have written a small ORM assembly for private purpose and wanted to check the connection string.
I had created a console application and add a reference to the assembly as I always did.
Project explorer has no warning with the file, object explorer sees all my types and namespaces in the assembly. But compiler can't resolve this reference for some reasons and I don't understand why.
I restarted Visual Studio (Express 2013) but it did not help.
Can somebody get an idea why it can't resolve that assembly reference?
My problem was in different versions of .Net: .dll had been complied for .NET 4.6.1 and Project for .NET 4.5.
I have checked the properties of a dll and there was 4.0 runtime version setted so i was sure that version is fine.
Only compilation warning helps me to realize the reason of this problem.
Unfortunatly i get used to skip them and didn't read it right after a compilation.
My target framework is .NET Framework 4.
The project is an MVC 3 project.
I'm using Visual Studio 2010.
Windows 7 64bit
I'm trying to get an old project working on my fresh install of Windows 7 64 bit. When I try to compile the project I get the following error multiple times:
Error 11 Missing compiler required member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'
I have read multiple questions on this same error but none of the solutions seems to work and are related to other target frameworks or different versions of MVC. Even more frustrating this exact same project compiles perfectly on my co-workers computer.
From what I understand, the reason I'm getting this error is because the project is looking for System.Runtime.CompilerServerices in System.Core but it was moved to mscorlib.
I am trying to re-ad mscorlib but when I try to add it as a compiled reference I get the following messages:
When I try to add mscorlib.dll 2.0:
A reference to 'mscorlib.dll' could not be added. The ActiveX type library 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.tlb' was exported from a .NET assembly and cannot be added as a reference. Add a reference to the .NET assembly instead.
When I try to add mscorlib.dll 2.4:
A reference to 'mscorlib.dll' could not be added. The ActiveX type library 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.tlb' was exported from a .NET assembly and cannot be added as a reference. Add a reference to the .NET assembly instead.
So when I try adding mscorlib v4.0.0.0 as a .NET reference I get the following error message:
A reference to 'mscorlib' could not be added. This component is already automatically referenced by the build system.
Am I missing a specific update? Do I need to re-reference mscorlib? If so how do I go about that? Is there a way to get the project to work with a System.Core.dll instead of mscorlib?
After some help, I have uninstalled .Net 4.5 and installed 4.0 which allowed for the project to compile, however I received the following error:
Could not load file or assembly 'Microsoft.VisualBasic.Activities.Compiler' or one of its dependencies. An attempt was made to load a program with an incorrect format.
To fix this, I then had to reinstall .Net 4.5 and reapply VS 2010 SP1. The project is now working!
I have an Umbraco/MVC project I have been working on using the current ( 6.1.6 ) version of Umbraco and building with the .Net Framework version 4.5.
I created the project as an empty MVC project then installed Umbraco through NuGet.
When it came to deployment time, my project didn't work on the live server because it turns out that only has the 4.0 version of the .net framework on it. I changed the "Build" property on my Visual Studio 2012 project so that it would target the older framework and as if by magic it now won't build at all.
I realised there was a versioning problem with the Umbraco dlls, so I downloaded the binaries again and installed them in the /bin folder on the production server. That now works correctly, but my local version still won't build with the 4.0 target, even though I am now referencing the current dll versions.
The thing that does my head in is that I can see the files.
The compiler says:
The type or namespace name 'editorControls' does not exist in the namespace 'umbraco' (are you missing an assembly reference?) C:\Users\Glenatron\Documents\Visual Studio 2012\Projects\MyProject\MyProject\usercontrols\customUpload.ascx.cs
The line using umbraco.editorControls.userControlGrapper has a wavy blue line under editorControls but if I start typing out the line again, intellisense has no problem identifying it.
I don't think this is really about Umbraco, I assume it is something to do with my environment in general.
I have emptied the bin folder and replaced my local reference dlls with ones downloaded from the Umbraco site. I have also removed and re-added all my references, to no avail. There are no versioned references in my csproj file.
I realise this is a relatively common problem - can anyone shed any light on what I need to do?
I have a c# solution that accesses a c++ project through COM. The project has to be targeted to a specific processor, in this case x64. I am using the Windows installer to install the application.
The first problem I ran into was the c++ dll was not being registered properly when installed, and the program couldn't access it. I solved this by adding the c++ project to the solution.
For a while this worked, and everything installed properly, but then I started getting the following warning when I tried to build:
The target version of the .NET Framework in the project does not match the .NET Framework launch condition version '.NET Framework 3.5'. Update the version of the .NET Framework launch condition to match the target version of the.NET Framework in the Advanced Compile Options Dialog Box (VB) or the Application Page (C#, F#).
The setup would not install if I tried ignoring the warning. After some searching, I found that the c++ project was building in .NET 4.0, while my solution used .NET 3.5. I tried changing my solution to 4.0, but for some reason it stopped working, so I changed the c++ to 3.5.
This worked for a couple of builds, but then I began getting the following errors:
Error: LNK1104 cannot open file 'mfc90.dll'.
I added the file to the Additional Dependencies section, but then another link error occured (mfcs90.dll) and when adding that one, I got an x86 x64 conflict.
I'm not sure why these solutions worked for a while and then stopped, and I can't seem to find a resolution at any step that works. If anyone has seen anything similar to this, the insight would be appreciated.
In order to include the Microsoft runtime dlls, you should not simply include the dll in your application directory. This won't help when the dlls have various dependencies and you might run into different conflicts and versioning issues.
The way I would recommend installing the runtime dlls for you application is to include the official merge module in your MSI.
See the following link for your options to redistribute the runtime library:
http://msdn.microsoft.com/en-us/library/ms235316(v=vs.90).aspx
I an earlier thread I got some help to track down a deprecated .Net assembly reference and I was successfully able to port my project to build within Visual Studio 2010.
Is there any option to get this ReportViewer to work within Mono? Building the project with MonoDevelp 2.2.2 currently gives me similar errors:
Assembly "Microsoft.ReportViewer.Common Version=8.0.0 [...] not found
Assembly "Microsoft.ReportViewer.WinForms [...] not found
Thanks for all help :)
Try running all of the dependent assemblies through the Mono Migration Analyser. It currently targets Mono 2.6, but 2.8 has recently been released.
If the assemblies pass the tests in that then they'll work fine in Mono. If they don't pass the tests then there's a slim chance that they'll work, it just depends which functionality is used.