Hello I just came across the exact same problem.
The issue for me was that in my plugin's app.config file the Microsoft.Data.Edm assembly was loaded before the Microsoft.Data.OData. So I moved the Microsoft.Data.Edm after the Data one and everything started playing as they should be.
Although I still cannot figure out when the app.config file subjects to modification.
Hope it helps,
Konstantinos.
Microsoft.Data.Edm
- 3
- 25
- 12/4/2015
- Poland
Found it. Understood it. Fixed it. :)
It looks like a bug left behind by Nuget during updates.
In full build log you can see entries like:
As you can see, MSBuild ignores installed nuget packages and goes right into PATH's.
After quick investigation I found that it first occurs in Nop.Web.Framework (same happens in Nop.Web and Nop.Admin).
Long story short, edit those three .csproj's and add Microsoft.Data.Edm, Microsoft.Data.OData, Microsoft.Data.Services.Client (and more if needed) references to nuget packages, you can find them in Nop.Services.csproj, or just copy those:
I guess it should be fixed properly by cleaning and reinstalling nuget references, but this fix is enough to keep it running.
It looks like a bug left behind by Nuget during updates.
In full build log you can see entries like:
Dependency "Microsoft.Data.Edm, Version=5.6.4.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35". (TaskId:13)
Resolved file path is "C:\Program Files (x86)\Microsoft WCF Data Services\5.6.4\bin\.NETFramework\Microsoft.Data.Edm.dll". (TaskId:13)
As you can see, MSBuild ignores installed nuget packages and goes right into PATH's.
After quick investigation I found that it first occurs in Nop.Web.Framework (same happens in Nop.Web and Nop.Admin).
Long story short, edit those three .csproj's and add Microsoft.Data.Edm, Microsoft.Data.OData, Microsoft.Data.Services.Client (and more if needed) references to nuget packages, you can find them in Nop.Services.csproj, or just copy those:
<Reference Include="Microsoft.Data.Edm, Version=5.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\packages\Microsoft.Data.Edm.5.7.0\lib\net40\Microsoft.Data.Edm.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Microsoft.Data.OData, Version=5.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\packages\Microsoft.Data.OData.5.7.0\lib\net40\Microsoft.Data.OData.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Microsoft.Data.Services.Client, Version=5.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\packages\Microsoft.Data.Services.Client.5.7.0\lib\net40\Microsoft.Data.Services.Client.dll</HintPath>
<Private>True</Private>
</Reference>
I guess it should be fixed properly by cleaning and reinstalling nuget references, but this fix is enough to keep it running.
- 62
- 410
- 1/19/2010
- United States
Using 3.7.0,
This issue seems to occur because of the compiling of the DLL's that get built into the bin of the Plugin folder pull the local machines Microsoft.Data.Edm, Microsoft.Data.OData, and Microsoft.Data.Services.Client and they don't reference the ones that Nop.Web bin compiles. I tried changing the copy local to false for all the DLL's in our plugin project. The other pre-installed plugins seem to not have this issue, only the ones that are build by us. We did, however, notice that our project has a different icon than the other pre-installed plugins. Is this because in the tutorials it says to use a blank MVC project instead of a class library to start a plugin? The icons on the other plugins show the 'class library' C# icon and our shows the window with the world icon.
Is there something there where we should be building our plugins using a 'Class Library' project instead of a blank MVC project?
The solution we found to help with the DLL issue is,
So when I use the Build and Deploy for our store, I have to go into the Nop.Web bin, copy the DLLs for those 3, which are dated 10/17/2016 and the version is 5.7.0.0 and then copy and paste those into the Plugins folder bin.
I also made a Post-build script for the Nop.Web project properties that copies the bin files from the solution bin to the Nop.Web project bin for debugging, but this does not cover when you use a deploy build. For some reason that does not work when you do a Deploy build.
A huge hassle.
Ideas about my question about the MVC project vs the Class Library project for plugins? And how to get it to NOT build the plugins Bin using my local machine's DLLs and to use the main Nop project DLLs instead?
This issue seems to occur because of the compiling of the DLL's that get built into the bin of the Plugin folder pull the local machines Microsoft.Data.Edm, Microsoft.Data.OData, and Microsoft.Data.Services.Client and they don't reference the ones that Nop.Web bin compiles. I tried changing the copy local to false for all the DLL's in our plugin project. The other pre-installed plugins seem to not have this issue, only the ones that are build by us. We did, however, notice that our project has a different icon than the other pre-installed plugins. Is this because in the tutorials it says to use a blank MVC project instead of a class library to start a plugin? The icons on the other plugins show the 'class library' C# icon and our shows the window with the world icon.
Is there something there where we should be building our plugins using a 'Class Library' project instead of a blank MVC project?
The solution we found to help with the DLL issue is,
So when I use the Build and Deploy for our store, I have to go into the Nop.Web bin, copy the DLLs for those 3, which are dated 10/17/2016 and the version is 5.7.0.0 and then copy and paste those into the Plugins folder bin.
I also made a Post-build script for the Nop.Web project properties that copies the bin files from the solution bin to the Nop.Web project bin for debugging, but this does not cover when you use a deploy build. For some reason that does not work when you do a Deploy build.
xcopy /Y "$(TargetDir)Microsoft.Data.Edm.dll" "$(SolutionDir)Presentation\Nop.Web\Plugins\bin"
xcopy /Y "$(TargetDir)Microsoft.Data.OData.dll" "$(SolutionDir)Presentation\Nop.Web\Plugins\bin"
xcopy /Y "$(TargetDir)Microsoft.Data.Services.Client.dll" "$(SolutionDir)Presentation\Nop.Web\Plugins\bin"
A huge hassle.
Ideas about my question about the MVC project vs the Class Library project for plugins? And how to get it to NOT build the plugins Bin using my local machine's DLLs and to use the main Nop project DLLs instead?
- 3
- 25
- 12/4/2015
- Poland
cmosqueda wrote:
And how to get it to NOT build the plugins Bin using my local machine's DLLs and to use the main Nop project DLLs instead?
In order to use dll's from local nuget packages you would need to fix nuget references or just add HintPaths to .csproj's by hand. I wrote about it before. (Maybe deleting and adding references directly do dll could fix it as well)
cmosqueda wrote:
Ideas about my question about the MVC project vs the Class Library project for plugins?
Sadly using MVC project won't work well right out of the box. However there are just three things you actually want from MVC project template: default references, Razor highlight/autocompletion in .cshtml and Razor compilation. It should be possible to create new project template based on class library and MVC template.
And how to get it to NOT build the plugins Bin using my local machine's DLLs and to use the main Nop project DLLs instead?
In order to use dll's from local nuget packages you would need to fix nuget references or just add HintPaths to .csproj's by hand. I wrote about it before. (Maybe deleting and adding references directly do dll could fix it as well)
cmosqueda wrote:
Ideas about my question about the MVC project vs the Class Library project for plugins?
Sadly using MVC project won't work well right out of the box. However there are just three things you actually want from MVC project template: default references, Razor highlight/autocompletion in .cshtml and Razor compilation. It should be possible to create new project template based on class library and MVC template.
- 62
- 410
- 1/19/2010
- United States
Hi a.zielinski_sprinter,
I did a full search of the project files for the reference tags for those DLLs.
The 2 cproj's I found were just Nop.Service.csproj and Nop.Web.csproj with those references.
But the version states 5.7.0.0 not the 5.6.4.0 on the reference.
I even looked at the Visual Studio Nuget Package Manager and it shows the DLLs we have installed are the 5.7.0.0 version.
I will keep digging.
Should we just add the references to those DLLs to our Plugin project? They aren't right now, so I think it takes the machines version.
I did a full search of the project files for the reference tags for those DLLs.
The 2 cproj's I found were just Nop.Service.csproj and Nop.Web.csproj with those references.
But the version states 5.7.0.0 not the 5.6.4.0 on the reference.
I even looked at the Visual Studio Nuget Package Manager and it shows the DLLs we have installed are the 5.7.0.0 version.
I will keep digging.
Should we just add the references to those DLLs to our Plugin project? They aren't right now, so I think it takes the machines version.
- 3
- 25
- 12/4/2015
- Poland
cmosqueda wrote:
The problem is not reference tag, but lack of proper HintPaths :)
Nuget references are broken in NOP 3.7 and reference resolver is retarded. Compilation crawls referenced libraries and notices Nop.Web requires Edm due to Nop.Services, then it happily ignores version and HintPath specified in Nop.Services and searches for Edm on its own because Nop.Web have no information on Edm version. So it goes .csproj location, C:\Windows, C:\Windows\system32... then goes for %PATH% and so on. If Edm is found there, it is copied and Nop.Web is built against whatever version it is. And it sometimes works because without specified version any will be allowed to load, in my case 5.6.4 was close enough to make it actually run.
And then you create plugin, reference bunch of dll's from "packages" by hand, including Edm with exact version number... and everything explodes on runtime because .NET is very strict about version mismatch.
That's how this fix looks like in changset (same thing for Nop.Admin, Nop.Web and Nop.Web.Framework, and on any project you click "Build" on):
You could try "Add reference" but have in mind that it is also imperfect, human supervision is advised ;)
Oh, and better avoid Visual 2015, it comes with new Nuget which goes crazy when it sees broken old Nuget :)
Hi a.zielinski_sprinter,
I did a full search of the project files for the reference tags for those DLLs.
The 2 cproj's I found were just Nop.Service.csproj and Nop.Web.csproj with those references.
But the version states 5.7.0.0 not the 5.6.4.0 on the reference.
I even looked at the Visual Studio Nuget Package Manager and it shows the DLLs we have installed are the 5.7.0.0 version.
I will keep digging.
Should we just add the references to those DLLs to our Plugin project? They aren't right now, so I think it takes the machines version.
I did a full search of the project files for the reference tags for those DLLs.
The 2 cproj's I found were just Nop.Service.csproj and Nop.Web.csproj with those references.
But the version states 5.7.0.0 not the 5.6.4.0 on the reference.
I even looked at the Visual Studio Nuget Package Manager and it shows the DLLs we have installed are the 5.7.0.0 version.
I will keep digging.
Should we just add the references to those DLLs to our Plugin project? They aren't right now, so I think it takes the machines version.
The problem is not reference tag, but lack of proper HintPaths :)
Nuget references are broken in NOP 3.7 and reference resolver is retarded. Compilation crawls referenced libraries and notices Nop.Web requires Edm due to Nop.Services, then it happily ignores version and HintPath specified in Nop.Services and searches for Edm on its own because Nop.Web have no information on Edm version. So it goes .csproj location, C:\Windows, C:\Windows\system32... then goes for %PATH% and so on. If Edm is found there, it is copied and Nop.Web is built against whatever version it is. And it sometimes works because without specified version any will be allowed to load, in my case 5.6.4 was close enough to make it actually run.
And then you create plugin, reference bunch of dll's from "packages" by hand, including Edm with exact version number... and everything explodes on runtime because .NET is very strict about version mismatch.
That's how this fix looks like in changset (same thing for Nop.Admin, Nop.Web and Nop.Web.Framework, and on any project you click "Build" on):
You could try "Add reference" but have in mind that it is also imperfect, human supervision is advised ;)
Oh, and better avoid Visual 2015, it comes with new Nuget which goes crazy when it sees broken old Nuget :)