I've got a project that uses Autofac, and the WebAPI integration
We run FxCop over our solution, and on opening autofac, I get the following:
The following indirectly-referenced assembly could not be found. This
assembly is not required for analysis, however, without it, analysis
results could be incomplete. This assemble was referenced by
Autofac.dll
System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes
This causes the following error on our CI server:
FxCop return code (516): PROJECT_LOAD_ERROR ASSEMBLY_REFERENCES_ERROR
Is there a way to tell FxCop to ignore this?
Had the same issue with AutoMapper 3.1.0 on our project. The real problem is an old version of FxCop. The last official release was FxCop 10.0, but new versions of FxCop have been bundled with Visual Studio since 2012.
I just replaced the FxCop 10.0 with the version that can be found in:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Team Tools\Static Analysis Tools\FxCop
or
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop
and the problem was solved.
This is a common FxCop thing when running with Portable Class Libraries. It's not Autofac; you just happen to see it because Autofac is the only PCL you're using. In my experience, this error doesn't seem to happen if you're building on a Windows 8 machine, but on Windows 7 or Server 2008R2 I see this a lot.
It's not a bug, and no, you won't find 2.0.5.0 on your machine. That version is actually for Silverlight and runtime .NET "stuff" handles redirection to the right assembly version. Unfortunately, FxCop is less cooperative.
I see the same thing in my build and solved it using the suggestions from questions like this: How to fix FxCop error code 512?
You must add a reference to the assembly's directory in the FxCop project file. For instance:
<Targets>
<AssemblyReferenceDirectories>
<Directory>C:/Windows/Microsoft.NET/assembly/GAC_MSIL/Microsoft.Web.Infrastructure/v4.0_1.0.0.0__31bf3856ad364e35/</Directory>
<Directory>C:/Windows/Microsoft.NET/assembly/GAC_MSIL/System.Web.Mvc/v4.0_3.0.0.0__31bf3856ad364e35/</Directory>
</AssemblyReferenceDirectories>
Workaround for this issue is to copy the missing System.Core.dll to the project output directory. I made this as a postbuild event to copy System.Core.dll from a shared folder to project\bin directory.
You can get the copy of System.Core.dll from the Silverlight SDK 2 installation.
Now fxcop runs successfully without any issues. Note that I was using Fxcop integrator for Visual Studio 2010.
Related
I'm trying to compile the SvnQuery project (https://github.com/kalyptorisk/svnquery.git) with the a version SharpSVN.dll which I created on my PC, but I keep seeing the error message CS0400: The type or namespace name 'SharpSvn' could not be found in the global namespace (are you missing an assembly reference?).
Using the SharpSVN.dll which comes with the SvnQuery source code, I do not see this error message, nor any other.
Both SharpSVN.dll files look the same when I open them in .NET Reflector, but there is one difference - the file which I created doesn't have version information. (To be exact: When you look at the file's properties in File Explorer, "File version" and "Product version" are empty.)
I followed these steps to create SharpSVN.dll:
Check out from https://ctf.open.collab.net/svn/repos/sharpsvn (tried trunk and the 1.1200x branch). Open VisualStudio command prompt (tried 2012, 2015 and 2017), cd to 'imports' folder, run 'nant build'. Result: no errors, but this doesn't create SharpSVN.dll (and I guess it shouldn't).
Now double-click SharpSvn.sln in the src folder. This opens VS2017. Compile Release|x86. Result: no errors, many warnings, SharpSVN.dll (with no version information) created in src\SharpSvn\bin\Win32\Release.
Any ideas about this issue?
Thanks...
I found the solution. My problem has nothing to do with the missing version number. In fact, I had compiled SharpSVN for a .NET version higher than that of the SvnQuery project. After increasing the .NET version number for SvnQuery and related projects, all compiled well. And SvnIndex.exe seems to run smoothly (test still ongoing).
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
I have DevExpress XtraReports v18.1.6 version and PostgreSQL 4 v3.3. Visual studio 2017 v15.3.3 and Windows 7.
Here is scenario: In my project, I have some reports writen in devexpress v17.2. I could not run those reports, because I could not download exactly that version 17.2, I install new 18.1.6. Then in Visual studio main menu "DevExpress" I click on "Project converter to 18.1.." and that action replace my old dlls v17.2 with new 18.1. After that I could run reports (see it in designer).
But problem is with databse connection. I created connection string with "XpoProvider=Postgres".
Every time when I want to get data in report, or rebuild result shema, or manage queries I get error:
Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0,...
I have that reference, exactly that version. Also I tried with new versions of threading.tasks but unsuccessfully.
My version of Npgsql.dll was 2.2.7, I tried with 3.2.5 (read from some devexpres documentations). Also tried with new 4.0.3.
Did anyone have a similar problem?
we had the same issue when using the DevExpress (18.1) Report Designer with Visual Studio 2017.
I know this might not be an ideal or the best solution but at least it worked for us:
I used ProcMon to determine where it was looking for that specific File, for me it turned out to be C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\hhfnlhs1.kna
I downloaded the NuGet Package for System.Threading.Tasks.Extensions from NuGet (https://www.nuget.org/packages/System.Threading.Tasks.Extensions/)
I unzipped the Package and stored the DLL at that path from step 1
I had to active "loadFromRemoteSources" in my machine-config (see https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/dd409252(v=vs.100))
I had to put another DLL from NuGet (https://www.nuget.org/packages/System.Runtime.CompilerServices.Unsafe/4.5.2) into that folder from step 1
That's it - now I can access the DB again.
We are using Work Flow's in our project and it is developed in VS 2010. Recently we migrated to VS 2013 Professional. Now when we try to open a Work Flow Activity in VS 2013, we get the following error message:
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.SharePoint.WorkflowExtensions, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. File name: 'Microsoft.VisualStudio.SharePoint.WorkflowExtensions, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'"
We could find the "Microsoft.VisualStudio.SharePoint.WorkflowExtensions.dll" under "C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\WorkflowDesigner", but still when we open the WF designer, we get the FileNotFound exception.
When we close and open the WF again, we get the below error message :
System.ArgumentException: An item with the same key has already been added.
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at Microsoft.VisualStudio.Activities.EditorPane.set_FileName(String value)
at Microsoft.VisualStudio.Activities.EditorPane.Microsoft.VisualStudio.Shell.Interop.IPersistFileFormat.Load(String fileName, UInt32 formatMode, Int32 readOnly)
Any idea what is causing the issue?
The exception is related to missing Workflow Manager or Workflow Manager Tools on the machine which might not have installed successfully with VS installation at first.
However, you can fix this issue by installing/reinstalling them and dependencies. You might need to restart the machine as well.
Here is the link to download the installers separately: http://www.microsoft.com/en-my/download/details.aspx?id=35375
Looks like we got the root cause now. There were some internet restrictions imposed on the PC's when VS 2013 was installed for which some of the WF related stuffs didn't get downloaded/updated properly.
We tried to re-install VS 2013 without Internet restrictions, and things started to work fine.
Hope this helps someone in need. :)
This worked for me: my workflow was referencing a custom activity I did not have in the /bin folder. Once I placed that custom activity (.dll) into the bin folder, I had no problems.
I'm trying to mole System.ServiceModel v4 in VS 2010 SP1 with Moles 0.94.51023.0 and I keep getting the following errror:
The type or namespace name 'IHttpCookieContainerManager' does not exist in the namespace 'ssm::System.ServiceModel.Channels' (are you missing an assembly reference?) [my-test-project.Test\obj\Debug\Moles\ssm\m.g.csproj] my-test-project.Test\m.g.cs 293022 43
This interface appears to have been removed from System.ServiceModel.dll in .NET 4.0 as I can only find it in System.ServiceModel.dll v2.0.5.0 (Silverlight) when I search in the Object Browser.
I'm able to reproduce this via the cmdline using moles.exe and I've tried altering the moles file to only generate type names I specify but it doesn't appear to make any difference. This was working fine prior to my upgrade to VS2010 SP1 so I suspect it's a bug, but any help would be appreciated.
Thanks
Nick
I debugged this on my own as well and found that the root cause appears to be that VS2010 SP1 (and the related GDR KB update for .NET 4) update one set of DLLs but not another:
The System.ServiceModel.dll in %ProgramFiles(x86)%\Referenced Assemblies\ doesn’t match the one in the .NET v4 install at %windir%\Microsoft.NET\Framework64\v4.0.30319...
Post VS 2010 SP1 update:
%Program Files(x86)%\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.ServiceModel.dll -> File version 4.0.30319.1
%windir%\Microsoft.NET\Framework64\v4.0.30319\System.ServiceModel.dll -> File version 4.0.30319.225
Comparing these two dlls in the Object Browser in VS as well as in Reflector yields the result that the IHttpCookieContainerManager interface has been removed in the newer file. So I suspect that this is a combination of .NET probing finding the newer DLL and Moles reflecting over the older one when doing mole/stub generation. I was able to manually generate a Moles dll for the newer DLL by running the Moles exe manually with no reference paths of any kind as opposed to the MSBuild target that adds a bunch of ref paths during a build.
I don't know why that happens, but I had the same issue, and I resolved it by using Moles type filters, and only including the ones I really need (which has the nice side-effect of speeding up compilation quite a lot!!). This is an example .moles file I'm using:
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name="System.ServiceModel"/>
<StubGeneration>
<Types>
<Clear/>
<Add Namespace="System.ServiceModel.Description!"/>
</Types>
</StubGeneration>
</Moles>
It looks like it was a conflict between the System and System.ServiceModel assemblies that Moles was using for compilation.
I had recently installed the Microsoft .NET Framework 4.5.
After uninstalling this and re-installing 4.0 everything worked.
Well, in case anyone is working with legacy code and happens to be cornered into using Microsoft Moles, I've done extensive digging on this topic and hope to save some from the anger and frustration I encountered.
I tried using the accepted answer's suggestion, which meant going to the Moles directory (in C:\Program Files..) and running the command line utility (moles.exe) as Administrator. There a lot of options, one of which allows you to include referenced assemblies (as suggested above).
However, even when trying to run the utility without referenced assemblies, the utility ultimately calls the C# compiler (csc.exe) with pre-defined referenced assembly paths, which is where I conclude that the confusion between .NET Framework versions occurs. I couldn't get it not to include these assembly paths.
My specific scenario was that I was trying to Mole a custom assembly, however because, apparently, I had .NET 4.5 installed on this machine, it was complaining upon compilation about System.Collections.Generics IReadOnlyCollection, IReadOnlyDictionary, and I think one other.
Solution: The only solution I got to work was to use Mole filters, which I read about on other posts and on the Microsoft Moles website (there is a special link for .NET 4.5 troubleshooting on the main page). In Visual Studio, I simply added the Moles assembly to my unit test project for my referenced custom assembly via right click in Solution Explorer. I then tried to build. For each error I received, I noted the offending classes and excluded them from being Shimmed or Stubbed by adding the following to the moles file:
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name = "MyCustomAssembly" />
<StubGeneration>
<Types>
<Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" />
</Types>
</StubGeneration>
<MoleGeneration>
<Types>
<Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" />
</Types>
</MoleGeneration>
</Moles>
Now clearly that's not going to work if you need the classes that you're excluding from mole/stub generation, however for my case it worked fine because the offending classes were not important and I wouldn't be needing to Stub or Shim anything in those classes.