I'm trying to run code analysis on my project and I'm plagued by lots of DLL resolve issues.
I've already Added a few dlls to the GAC using gacutil and solved a few issues that way, however I'm seeing an error regarding a reference to System.Net.Http version 2.0.0.0.
I don't have a single reference to this DLL in my solution, I don't have this DLL anywhere on my machine in fact, only version 1.0.0.0 or 4.0.0.0.
I do have a binding redirect for this dll in my config file for the web site but obviously the code analysis process isn't using this.
I'm not sure how best to proceed with this. Can I configure code analysis to use the binding redirects? Or do I need to go hunting for DLLs online in order to GAC them?
Would appreciate any ideas, thanks.
I decided to just GAC version 1.0.0.0 and code analysis is now working fine ...
Related
I made a new .NET Class Library solution if TFS, and added a bunch of preexisting classes that were developed for a windows forms application. Basically just dumped the old folder in. The forms app worked fine and the folders in bin were expectedly barren, apart from the exe and the required nuget references. The dll build however copies over libraries all the way from Microsoft.Win32.Primitives.dll, to System.Xml.XPath.XDocument.dll for no apparent reason. I have removed unused references with ReSharper and commented out unnecessary using statements. No difference whatsoever. I don't think it's a problem from the deployment perspective, it's just annoying to have so many files copied over each build. Could it be that the initial presence of Forms just poisoned the new project forever? Any help whatsoever would be much appreciated.
Prevent Visual studio 2017 from copying almost 100 unnecessary system
dlls to output folder for dll project
Please check if your VS2017 is very old and also check if the framework version of your project targets to 4.6 or 4.7.1.
If so, there is an known issue about this issue.
This is a .net standard 2.0/net 4.6/4.7.1 issue which was improved in 4.7.2. You can check this similar issue.
Suggestion
1) you should first update your VS2017 in case some updates fix it.
2) change the framework version of your project to net framework 4.7.2.(if you do not have net frameowork 4.7.2, you should install it in the VS Installer)
I am working on a C++/CLI project with VS 2012 in Dynamic Library (.dll) and x64 mode.
If I switch the mode to Static Library, I get the error below.
Error 1 error C1107: could not find assembly 'mscorlib.dll': please specify the assembly search path using /AI or by setting the LIBPATH environment variable C:\Depot\Main\Current\Sln\ALibraryProject\Stdafx.cpp 1 1 ALibraryProject
I tried removing the reference to the mscorlib.dll then adding it again from:
Project > Properties > General > Common Properties
But that didn't help. As I know that VS handles the reference to the .NET assemblies, I don't want to add a disk file reference to it as it seems illogical! Did anybody face this before?
I had the same problem when converting my solution from the VS2010 compiler to VS2013 compiler.
I resolved it by changing the project settings (for the project containing the managed .cpp file that was throwing this error) as follows: In Project Settings | C/C++ | General | Additional #using Directories I added the macro $(FrameworkPathOverride). This resolves to the reference assembly directory for the version of .NET that you're targeting, which in my case is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.1
If I switch the mode to Static Library
This is not the typical error you get when you try to build a static library with /clr in effect. I'd have to assume you've been tinkering with project settings to get rid of the inscrutable linker errors you get when you try to do this.
Core issue is that the C++/CLI build system doesn't support static libraries that contain MSIL. Managed code doesn't use a linker, binding happens at runtime. Which makes the essential difference between static libraries and DLLs disappear. So Microsoft decided to not support it because it didn't make much sense to implement it. Unfortunately they don't yell loud enough when you try to do it anyway, the linker errors you get don't give enough of a hint what you did wrong. Workarounds, like merging with ILMerge don't work either, it cannot deal with mixed-mode assemblies. Merging the native code sections and their associated relocation table entries is very untrivial.
Keep in mind that it is fine to link native static libraries. A typical C++/CLI project has only the ref class wrappers that need to be built with /clr in effect. You can glue any amount of native code from libraries into the final assembly.
I'm forced to theorize about the actual compile error, too many programmers get this error for another reason that doesn't have anything to do with building static libraries and they are harassing me in the comments.
Do beware that targeting a different version of .NET than the one you have installed on your machine is quite a hazardous affair, particularly so if you want to target 4.0 and you have 4.5.x installed. The key element in your .vcxproj file is the <TargetFrameworkVersion>. This will be missing if you started the project targeting an old .NET version, you have to insert it yourself. The IDE also doesn't support changing it if it is present, again edit by hand.
Which is enough to coax MSBuild into generating the proper compile command. You can verify if that panned-out well, look in the *.tlog subdirectory of the Debug build directory for your project. The cl.command.1.tlog file shows the options that were passed to the compiler. It should contain:
/AI"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
/FU"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\mscorlib.dll"
Note the subdirectory, very important that it matches your intended .NET target. v4.0 in this example. And very, very important that it does not point to c:\windows\microsoft.net, the legacy location for reference assemblies.
I have the same problem. Having a dll doesn't work, as I need to provide a native C++ wrapper for a .net object so it can fulfil a natice c++ interface - I can't use .net in a dll interface - this gives a compile error
This worked as a static library in VS 2010 (with .net 4)
Some of my executables and dlls which also have some code with /clr. They don't have an issue. I'm not trying to make a net Lbirary.
I solved it by removing dependency in old and not updated mixed lib, which was also configured only in Debug configuration, and as result, it started to get the same error as yours after I changed some code.
It was not simple to find it, because error is not clear, and the dependency was set up via "Additional Dependencies" in project settings.
Open visual studio and unload your project then Go to the project folder and open file .vcxproj . Search for tag "targetFrameworkVersion"
(if not present it means ur project is not using dot net frameworks.so no requirement of change)
Change it to required version
Save the file.
And now reload the project .
I am upgrading an SP2007 project to SP2010 where I have made the necessary changes to the project(changed the reference, master pages, etc.). I have deployed the farm solution in my machine I am getting the following error:
Cannot add the specified assembly to the global assembly cache: System.Web.Extensions.dll.
I have referenced this DLL in my project.
Could anyone help me to resolve this issue?
Another good idea is to include an iisreset and a Restart-Timer SPtimerv4 while deploying, as this will help to release similar locks.
However, do you really need to deploy System.Web.Extensions with your WSP now that you've upgraded to 2010? Since 2010 runs on .Net framework 3.5 it should already be present on your server..
Best regards,
Rikard
Just grabbed the latest .zip release of the orchard CMS from http://orchard.codeplex.com/releases/view/65184 and have opened this via VS2010 by pointing
at the extracted folder.
When I attempt to compile I get the following error:
The type or namespace name 'Blogs' does not exist in the namespace 'Orchard' (are you missing an assembly reference?)
Any thoughts?
You need to either:
download the recommended download and run that directly without compiling. It simply does not have what's necessary to recompile everything. It only knows how to dynamically compile modules and themes at runtime.
download the full source code and compile that in VS
If you are going to use VS, I highly recommend you use the full source code.
I'm not sure what's in that zip but if this is ur first look at orchard, try using webmatrix. It's fairly painless.
Orchard is not a conventional mvc app. It has a core needs to be compiled but the modules are compiled at runtime. If the core isn't compiled in that zip you'll need to open the project from the sln file in visual studio. If it is compiled you might need to setup the web directory as a virtual directory in iis.
I found it easier to familiarize myself with orchard in webmatrix first. There is enough in that to keep u busy for a bit!
Hope that helps
I am using WSPBuilder to build a wsp file for sharepoint. One of my referenced dll's is obfuscated with .Net Reactor. When building the wsp project, this dll is not recognized, the WSPbuilder is throwing an error. I am not with the solution of installing this dll manually as it should be part of a complete setup on a sharepoint farm with multiple web front ends.
Any solution or idea for a workaround?
The error i am getting is this:
Unable to resolve assembly 'WSPBuilder.XmlSerializers, Version=0.9.8.206, Culture=neutral, PublicKeyToken=2b778c59697d7d9e', please use DLLReferencePath to point to the directory where this DLL is located.
Thanks.
This problem is solved with WSPBuilder ver. 0.9.8.0406
See Unable to resolve assembly WSPBuilder.XmlSerializers