I have several custom modules in separated projects (class libraries), not directly in the website-project itself. My predecessor used to work with Visual Studio 2008 in order to edit the modules.
Now, after migrating the project to Visual Studio 2012, I've got strange errors telling me about required references to the DotNetNuke - Assembly. This assemblies reside in the bin-folder of the correspondenting project, nothing has changed there since the migration:
The references seem to be okay:
I can hit F12 on e.g. TabController (which resides in DotNetNuke.Entities.Tabs), this would open the object browser as expected. I can't see what's wrong here. When I compile, the error-list is full of Reference required to assembly 'DotNetNuke, Version=5.0.0.799, Culture=neutral, PublicKeyToken=null' containing the type 'DotNetNuke.Entities.Tabs.TabInfo'. or similar.
I remember vaguely that there was "DotNetNuke Project Templates" installed in the old Visual Studio 2008. Could that be an issue, too?
Related
I have a DLL project in Visual Studio 2015 with properties:
However on the left hand side, I see "Librarian" rather than "Linker" options. Also on build I get undefined symbols for all referenced libraries (the project references a few projects in the solutions which build as static lib).
To note:
I converted the project from a static lib to a DLL by changing the "Configuration Type" option.
I have applied, saved, closed, reopened
Linked projects are of same type (e.g. Debug/x64) for this solution configuration.
This could be a VS2015 bug?
Note perhaps similar question for previous version of Visual Studio
In Visual Studio 2012 what is the difference between Librarian and Linker?
(however the question doesn't specify that it's a DLL project)
The problem is that the DLL project had a property sheet which sets the project as a static library, and had a libraries section.
It seems setting your project settings to DLL cannot override this kind of property sheet.
I'm working with some application handed over by another person in which I must document the requirements, build and deploy processes.
The problem here is that Visual Studio (2005) is throwing a lot of errors since it can't find the references for the dlls.
This obviously won't let VS build the project.
Everything works fine on the persons computer but not on mine, even though the project references the same folder where the dlls are, the bin folder.
How can I circumvent these problems and get VS to properly reference the dlls?
The following printscreen shows the references screen for the project.
My guess is that your DLL uses a more recent .NET framework than your application does.
Check the properties for your DLL source (right-click on the DLL code in the solution explorer and choose Properties). Go to Application - Target .NET framework and compare the version to the one the application itself uses (right-click on the project code). Note: under your application properties check both the settings under Application - Target .NET framework AND under Publish - Prerequisites.
For what it's worth, even after changing the .vbproj file and removing many lines about hard coded values,
I eventually checked out the project again removed all references to the given DLL and then added it using the GUI.
Lesson learned, don't try to change out one DLL for a newer version without using VB2005 GUI.
The easiest solution will probably be to transfer everything to another project. It will be incredibly time consuming to find where visual studio has left the hard coded path at.
WOOT!!!! Compile the DLL file to a lower version of the .NET framework, and it will fix the problem!!!!
The paths in the project file cannot be the same or the assemblies referenced have a different version.
It might be worth unloading your project and the editing it to inspect where it's looking and for what version.
I had the same problem with an older Visual Studio Project that I opened in Visual Studio 2008. I tried to add new references to the project and got permanent errors that the dll's cannot be found. After the migration of the Project to Visual Studio 2010 I got the following error message when I tried to add a new reference:
'mySample.dll' or one of its dependencies, requires a later version of the .NET Framework than the one specified in the project. You can change ...
After changing the projects .NET Framework to a newer version everything works fine.
Good suggestions in other answers. In my case, it was because the libraries weren't copied (downloaded) successfully: the files existed, but were 0 kB.
Did a clean, which removed all the DLL's and then VS2008 complained it couldn't find the references (Duh!!!) and wouldn't rebuild....luckily I had and old version of the dll's and replaced them in the directory AND THEN did a rebuild to replace them...all references are now OK and we're back to normal....good old VS 2008
Actually I already resolved this issue but still I'm not really happy with the way I resolved this issue.
I have VS2010 SP1 and I need SP1 to work with Azure SDK.
First of all installing Pex and Moles somehow created problems with System.XML.dll. It just disappeared from References in all projects. I had to explicitly find it and connect it to all solutions that used it.
Also, there was a bigger issue with Moles itself. TestProjects just weren't able to find
Microsoft.Moles.Framework.dll. And it generated all kinds of errors.
When I tried to add reference to Microsoft.Moles.Framework in "Add Refernce" dialog I got message: "Microsoft.Moles.Framework, Version=0.94.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" is incompatible with .NET Framework 4
Solution was to explicitly add reference to Microsoft.Moles.Framework.dll in C:\Program Files\Microsoft Moles\PublicAssembliesSilverlight. And after that all works fine so far.
I hope this info can be helpfull to someone.
I've created a class library in Visual Studio 2008, and when I try to add the dll as a reference, I get the message in the title for the Path field in my project references. I've been going for a week trying to figure out this issue, and I haven't been able to come up with anything. The strange thing is I can add the same reference to a Visual Studio 2010 project, and it works perfectly fine.
I used VS 2008 to build it because the dll isn't used in house and needs to be compatible with .Net 3.5. Any ideas?
EDIT: I also found out that referencing the dll in a c# project works fine as well. It's only Visual Basic that's causing me problems.
Resolution
Using DependencyWalker, I was able to find out that some obscure dll was indirectly being
referenced (IEShims.dll) but couldn't be found. After a little more trial and error, I found my project had a specified reference path (Project Properties -> References -> Reference Paths) that pointed to the project's DEBUG directory. I had to remove that reference path, which then resolved the above issue.
I am having a strange problem since installing the latest version of ODAC, 11.2.0.2.1. I installed both the 32-bit and 64-bit versions because I develop applications for both architectures. My computer is Win 7 64-bit.
Since installing ODAC and referencing the new 64-bit version of ODP.NET, one of my web application projects in Visual Studio 2010 gives the following warning for all aspx pages and masterpages when I view them in Markup View.
ASP.NET runtime error: Could not load file or assembly 'Oracle.DataAccess' or one of its dependencies. An attempt was made to load a program with an incorrect format.
The warning is limited to Markup View. The web application builds and runs fine. I tried cleaning the VS Temporary ASP.NET Files, but that did not fix the issue. I removed all references to Oracle.DataAccess throughout my application, and then readded them to be sure that all the references were correct. The web app is compiled to 'Any CPU' but it uses the 64-bit Oracle.DataAccess. I created a new project, and referenced the same projects and dlls, and I do not get the warning, so it appears to be specific to this project file.
Any ideas why I would get the warning when in Markup View?
Expressly set the "Platform target" to "x86" or "x64" in the project properties --> Build tab.
Do NOT set it to "Any CPU." This is one of many common conditions which causes this driver of typical Oracle software quality to have a nervous breakdown.
Turns out the ODAC 11.2.0.2 xcopy installer doesn't correctly register all of the dlls (See bottom answer). As a result, Oracle.DataAccess.dll (64bit) was being copied into the BIN directory, and VS was trying to load it when in Markup View causing the warning. After manually registering the missing DLLs and rebooting, I am no longer having the problem.
Ideas you can check:
Check the Oracle.DataAccess reference in your Visual Studio project has the 'Specific Version' property set to 'False' (this is not the default).
Use the Fuslogvw.exe to determine what are the locations the .NET Framework is trying