I added references to telerik dlls in the code, with copy local set to true. But, when I am building the project I am receiving an error randomly.
Error1Unknown build error, 'Cannot resolve dependency to assembly 'Telerik.OpenAccess, Version=2015.1.220.1, Culture=neutral, PublicKeyToken=7ce17eeaf1d59342' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.' C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets2689SMS
I am not using openaccess assembly at all. I have no idea why this keeps coming randomly. I am not even able to find the dll anywhere to add it to the project.
I was trying to use the telerik controls by dropping them to designer from the toolbox (just like typical asp.net controls). Somehow in that case, it was referencing the path of the installation folder (C:\ProgramFiles...). That's why it was failing on different PCs wherever the installation path changed (like telerik 2.0.2 instead of telerik 2.1.2).
So, I copied all the dlls from installation path, uninstalled telerik completely. Then I copied the required dll to bin folder and referenced it in solution from there.
Related
I have a DotNetCore 2.1 Web App (just created it today from the VS 2017 scaffold). This solution also includes a DotNet Core 2.1 Library DLL project. The solution builds ok.
I have another (brand new) DotNetCore 2.1 Web App that wants to use the Library DLL. But when I try to add a new reference (on the Browse tab), it complains:
One or more errors occurred.
The reference is invalid or unsupported.
Any suggestions?
(Curiously, the DLL doesn't show up directly under the Bin\Debug folder like it does in classic .Net; It's under Bin\Debug\netcoreapp2.1)
I got this error after I moved some of my code repos around and suddenly my .NET Core 2.1 console app wouldn't recognize a .NET 4.5 DLL anymore when I added it.
Turned out that although the broken reference did not show in the solution explorer, the project file still contained it, along with the now broken HintPath to the DLL's old location. Manually removing this reference from the project file solved it.
Go into your .csproj and make sure the <Reference Include=... is pointing to the correct directory.
For example, my references were pointing to the bin\Debug path of another project when the only build that was actually there was the bin\Release
When you create a new project from the Visual Studio 2017 Class Library (.NET Core) template, the csproj file contains:
<TargetFramework>netcoreapp2.1</TargetFramework>
Since this is a library, it (apparently) needs to target netstandard2.0. (BTW, creating a library project from the dotnet command line command correctly targets netstandard2.0. Go figure.)
So changing the line in the library's csproj file to
<TargetFramework>netstandard2.0</TargetFramework>
and rebuilding the library now allows me to reference the library from the DotNet Core 2.1 (netcoreapp2.1) application.
I am converting lots of projects to .net6, and one of the projects suddenly refused to let me add .dll files. The solution was to remove the old references first, then add the new references. (The project had references to old .dll files with the same name as the new converted ones.)
Normally Visual Studio lets me add two dlls with the same name but different path, so I later can erase the old one, but in this particular case this did not work. A screenshot and Paint to the rescue for my memory!
In my case, I had a reference to duplicated .dll files. After removing duplication and changing references to different folders got the error above. Cleaning obj, bin and removing the .vs folder from the root directory helped
For me I had to add a nuget package instead of manually adding a reference. I was using .net 6 and needed System.Drawing so I added the System.Drawing.Common package.
https://www.nuget.org/packages/System.Drawing.Common/
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
I am trying to make a program that works on every operating system by forcing it to load and use the DLL's in the current directory, not the windows directory, but it don't works. I tried to enable "copy local" and change the refference path, but without any success, the program tries to load the DLL's from the windows directory.
My question is: how can I fix this?
The Search Order for DLL's is documented here on MSDN. It also includes instructions on how you can modify the search order so that the local bin directory is searched first, instead of the GAC.
The directory %windir%\assembly is called the GAC. Assemblies are not copied there, but installed typically using gacutil /i or by installation packages.
GAC is a suitable folder for libraries referenced by lots of other libraries and applications in build versions that are not centrally coordinated. Using GAC allows you to have multiple versions of the same library, all of which might be indirectly required even by a single application, installed side by side on the system. Case in point is the .NET framework itself.
The assemblies that you build are probably not that kind. Application assemblies and libraries that are basically part of a single application should never make it to the GAC or you can get into trouble. There is a variety of possible trouble:
one accidentally or intentionally creates different (incompatible) builds of the same library with the same version number.
assembly in GAC references an assembly not in GAC
one app installs the same assembly into GAC, but another app wants to load it from its local folder (where application binaries reside).
Code in the GAC gets a preference when assemblies are loaded. To remove an assembly from the GAC, use gacutil /u.
I am trying to troubleshoot a VB.NET project that contains UserControls (actually, several of them that are displaying the same issues). I am trying to get them to build under x64, but it is impossible. In x86 or AnyCPU, the UserControl builds and shows up in the Toolbox, so I can add or modify it in the forms that require it. In x64, the controls disappear from the Toolbox, I get warnings during build (the current project builds though), I can't see any of the forms - I get errors (please see below) - and projects that require the project with the form as an import will not build.
When I was studying what these UserControls are so that I can maybe rebuild them from scratch, I downloaded code from a book - great learning tool, but I get the same errors:
Could not find type 'Chap15SampleCode.ListSelector'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built using settings for your current platform or Any CPU.
The variable 'ListSelector1' is either undeclared or was never assigned.
I also get warnings, not sure what to do about them:
Possible problem detected while building assembly 'Chap15SampleCode': Referenced assembly 'mscorlib.dll' targets a different processor
Possible problem detected while building assembly 'Chap15SampleCode': Referenced assembly 'System.Data.dll' targets a different processor
I checked and found System.Data as a Reference is in c:\Windows\Microsoft.NET\Framework... (if I change the target framework to 4.0 the Reference is in c:\ProgramFiles(x86)... that was what my projects had ... and I tried to change it because of the x86, I couldn't, I had a few others in ProgramFiles(x86) and I thought that may be the problem ?)
Reinstalled VS2010, reinstalled Windows - did the same before btw - but I do have a clean system so I can't blame it.
If I can get this simple project to work, I hope the real projects will be easy - Please help me figure out what this is about. Thank you.
You have changed the Platform target setting in the project to x64. This is not appropriate for any project that produces a DLL. The actual bitness of a process that uses your DLL is determined by the EXE that starts the process. Or the host in which your DLL runs, the case for Visual Studio which is a 32-bit process. There is nothing a DLL can do to force the bitness, it can only refuse to get loaded. Which is what you see happening.
Change the setting back to AnyCPU so that your UserControl will work correctly in any process, regardless of its bitness. Including the VS designer. Project + Properties, Build tab. For VB.NET it is located in the Compile tab, Advanced Compile Options button.
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