I have a c# project GenericBusinessObject and a project WebRole, which uses GenericBusinessObject. WebRole has a BusinessObject Workitem, that implements the Interface method IFastSearchable.IndexDocument that is called from within GenericBusinessObject.
Actually the WorkitemBusinesObject is declared in WebRole as GenericBusinessObject.
I refer both project dlls from LinqPad. But LinqPad fails with an exception.
TypeLoadException: Die Methode "IndexDocument" im Typ "WorkstreamPlatform_WebRole.Models.Workitem" der Assembly "WorkstreamPlatform_WebRole, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" hat keine Implementierung.
LinqPad thinks that Workitem has no implementation of the IndexDocument method. Which is wrong.
Is it a LinqPad bug or am I thinking wrong?
In normal project execution it works.
Usually what I find in these situations with TypeLoadException is that it is related to using different versions of the .NET framework. For example, if you are running version 2.x of LP instead of 4.x while referencing a dll build with 4.x.
I'd look to make sure all versions of the code are compatible. 2.x for LP is 3.5 and 4.x is for 4.0.
Related
I have the following stack with an XAF Winforms, Entity Framework Project;
Framework 4.72 exe which references
Framework 4.7.2 library1 which references
.Net Standard 2.0 library2 which references
.Net Standard 2.0 library3
A call down the stack to a method in library3 produces an exception.
System.IO.FileNotFoundException
HResult=0x80070002
Message=Could not load file or assembly 'Microsoft.EntityFrameworkCore, Version=3.1.9.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The system cannot find the file specified.
I was able to replicate the problem in a Framework 4.7.2 unit test that called Library2 directly and to solve that.
To solve the problem in the unit test I used BindingRedirectGenerator to generate the runtime section of the unit test app.config as per the answer to my question here
However this does not work when I use the generated section for the application app.config
[Update]
I think the issue is that Library3 calls a framework library... investigating.
This is a form of the question I asked here
Yet even after having asked the question before I still got caught.
The solution was to create a unit test project with a dialog box, then, at the message box, run BindingRedirectGenerator to make the app.config
I am up for advice on whether this question is useful (since the problem was encountered a different way) or should be closed.
The issue in not getting the technique working for the .exe appears to be a new problem to do with calling a framework library from a standard library.
Targeting Framework 4.6.1 and creating an Azure Function using VS2017 which uses EF Core 2. I'm getting the error:
Could not load file or assembly 'System.ValueTuple, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies.
...which I normally solve with a bindingRedirect in the app.config file. Since Azure Functions don't use app.config, is there a way to solve this? Do I need to use EF 6 instead?
Functions are loaded into the same process as Azure Functions, so you only have access to the same version of the assemblies that the runtime pre-loads.
This is a know issue and there is work being done on it. I believe they are working on some kind of "language service" where we'll have complete control over what assemblies are loaded.
Until then, there are some work-arounds:
Azure Functions binding redirect
I create a console application in Visual Studio 2015 RC and add Automapper 3.3.1 using nuget to the project.
If I then add the following snippet to my project:
public class Class1
{
public void Test()
{
AutoMapper.Mapper.Map<B>(new A());
}
}
And then open the same project in Visual Studio Code preview on Windows 10 then I get a red squiggly on the Map function.
The error message says:
The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes'.
My project is configured to use .NET 4.52 and there are absolutely no errors or warnings when building the same project using visual studio 2015 RC or using MSBuild from the command line.
Automapper is portable class library and this is what seems to trigger the problem.
Is this a known issue with Visual Studio Code or Omnisharp?
Are there any way to suppress these error messages?
Update:
I have now tested with VS Code version 0.3 and it is still not fixed.
To make it even simpler to reproduce I have also verified that the problem also exist for a ClassLibrary project containing only the 3 classes: Class1 as shown and class A and class B, which are just two dummy classes used to have something to map.
It does not matter which version of Visual Studio is used to create the project. The same problem exist if I create the class library project using VS 2013.
Maybe you added the reference in both dnx451 and dnxcore50 in project.json file.
I think the problem is Automapper did not support .NET Core 5.0, please refer this article for more detail about .NET core 5.0 and .NET framework 4.6.
http://blogs.msdn.com/b/cesardelatorre/archive/2014/11/18/what-is-net-core-5-and-asp-net-5-within-net-2015-preview.aspx.
This might be the limitation of multi-environment in .NET Core 5.0 when using available libraries. You should write by yourself or waiting for other libraries update if you want to use, otherwise, please remove dnxcore50 in project.json.
Happy coding!
This is actually a known issue with the OmniSharp-roslyn server which powers VS Code, see: https://github.com/OmniSharp/omnisharp-roslyn/issues/265
I suspect you might have better luck using the yeoman ASP.NET 5 generator to generate an ASP.NET 5 Console application.
See: http://docs.asp.net/en/latest/client-side/yeoman.html
And http://docs.asp.net/en/latest/dnx/console.html
I'm trying to use LINQPad 4 (the latest beta) with Entity Framework POCO classes. I take the normal path of creating a new connection and then selecting "Entity Framework DbContext POCO(4.1) and then selecting my he assembly holding my classes. When I do so I get the following message
"Could not load file or assembly EntityFramework. Version=4.1.O.O,
Culture= neutral, PublicKeyToken=b77a5c561934e089 or one of its dependencies.
The system cannot find the file specified."
I'm able to load the assembly from my application just fine. What gives? It seems a bit different from the previous problem like this reported in the CTP.
I had the same problem today, this is how I solved it:
Apparently the LINQPad 4.36.3 requires in some way Entity Framework 4.2 :/
It was released last week: ADO.NET blog
What I did is:
Installed EF4.2 via NuGet
Rebuilt the project
Copied all my project .dll files to LINQPad folder (including the 4.2 EF.dll)
I read here that I need to add something to the LINQPad.exe.config file but it was already there..
[At this point I tried removing that assembly redirect and ran it against my 4.1 dll, did not work, was still looking for 4.2]
Closed VS and uninstalled EF4.1
Thats it, after that both my project is now running on 4.2 and LINQPad works as well.
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.