EWSoftware / SHFB

Sandcastle Help File Builder (SHFB). A standalone GUI, Visual Studio integration package, and MSBuild tasks providing full configuration and extensibility for building help files with the Sandcastle tools.
Other
2.19k stars 369 forks source link

.net standard build fails for local repository #599

Closed AshwinKamathB closed 6 years ago

AshwinKamathB commented 6 years ago

We have a scenario where a dll gets referred via nuget from local repository.When we use the referring DLL project as document source and compile it throws following error

The Czm.Czi.DeviceGateway.DTO comes from local nuget repository

MRefBuilder : error : Unresolved assembly reference: Czm.Czi.DeviceGateway.DTO (Czm.Czi.DeviceGateway.DTO, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) required by Czm.GenericDevice.Listener.Interfaces [E:\GD\Main\Runtime\Release\Listener\netstandard2.0\PackageDocumentation\Documentation\Working\GenerateRefInfo.proj]

Also I am getting following error in build

Encountered conflict between 'Reference:C:\Users\kjnrc1.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\ref\System.Xml.ReaderWriter.dll' and 'Reference:C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\System.Xml.ReaderWriter.dll'. Choosing 'Reference:C:\Users\kjnrc1.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\ref\System.Xml.ReaderWriter.dll' because file version '4.6.25519.3' is greater than '4.6.25507.1'.

How to solve above error....

Version: 17.5.15.0 VS : 2017 Project: .Net standard Framework-Version: Cross-platform (.Net core/ .Net standard)

EWSoftware commented 6 years ago

Can you provide an example so I can duplicate the problem?

AshwinKamathB commented 6 years ago

First Scenario:

Create a .Net Standard DLL and Push it to your local repository.

Try to refer the DLL in the other project which is Document Source for shfbj project. Now try build shfbj project you get above error.

The DLL which is referred from nuget.org works fine.Any dll which is referred from local repository has the problem

EWSoftware commented 6 years ago

Sorry, I haven't used .NET Standard so I am not familiar with how the projects work and that means nothing to me. Can you provide an example I can just build?

AshwinKamathB commented 6 years ago

I can give u team viewer access can i get mail id .Also can we have a debug session to show case you what problem we are facing.

Mail id: ak311988@gmail.com

EWSoftware commented 6 years ago

A simple example that demonstrates the issue is all I need. You can e-mail it to me. As long as it builds and fails in the same way, I should be able to handle it from there. I don't have the time to provide live, one on one support. My e-mail address is in my profile.

eriawan commented 6 years ago

@AshwinKamathB

Your issue is actually different things, and as far as I know it's not related to Sandcastle (SHFB) at all.

First, separate the problems. The first error: MRefBuilder : error : Unresolved assembly reference: Czm.Czi.DeviceGateway.DTO (Czm.Czi.DeviceGateway.DTO, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) required by Czm.GenericDevice.Listener.Interfaces [E:\GD\Main\Runtime\Release\Listener\netstandard2.0\PackageDocumentation\Documentation\Working\GenerateRefInfo.proj]

is caused by the fact that the nuget source isn't reachable by MSBUILD.

This error: Encountered conflict between 'Reference:C:\Users\kjnrc1.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\ref\System.Xml.ReaderWriter.dll' and 'Reference:C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\System.Xml.ReaderWriter.dll'. Choosing 'Reference:C:\Users\kjnrc1.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\ref\System.Xml.ReaderWriter.dll' because file version '4.6.25519.3' is greater than '4.6.25507.1'.

is basically caused by referencing .NET Standard dll (including .NET Standard targeted nuget packages) within legacy .NET Framework projects. I mean legacy because .NET Standard/.NET Core project is using SDK format in the header of the csproj:

<Project Sdk=""Microsoft.NET.Sdk">

instead of:

<Project Toolsversion="15.0" ... >

To solve this, you should add <ImplicitlyExpandNETStandardFacades /> inside your csproject. This is the current behavior of MSBUILD when resolving non-SDK projects that have references to .NET Standard libraries. For example: https://github.com/Microsoft/msbuild/issues/2527

@EWSoftware could we close this issue instead? Based on my explanation above, IMHO it's not related to SHFB at all.

EWSoftware commented 6 years ago

@eriawan: Regarding the unresolved assembly reference, you may be right. However, I believe the second part about the conflicting references is coming from the SHFB intermediate project GenerateRefInfo.proj used to generate the reflection information, not the .csproj used as a documentation source.

The build engine scans for PackageReference elements and adds the related assemblies to the GenerateRefInfo.proj to pass to the MRefBuilder tool. It's more likely than not that the targets file included to resolve the references has issues with them. Adding <ImplicitlyExpandNETStandardFacades /> to it might resolve that issue.

AshwinKamathB commented 6 years ago

First issue are you going to fix ?Like is there any work around because now we need to do hard reference to resolve the issue On Tue, 15 May 2018 at 1:48 AM, Eric Woodruff notifications@github.com wrote:

@eriawan https://github.com/eriawan: Regarding the unresolved assembly reference, you may be right. However, I believe the second part about the conflicting references is coming from the SHFB intermediate project GenerateRefInfo.proj used to generate the reflection information, not the .csproj used as a documentation source.

The build engine scans for PackageReference elements and adds the related assemblies to the GenerateRefInfo.proj to pass to the MRefBuilder tool. It's more likely than not that the targets file included to resolve the references has issues with them. Adding <ImplicitlyExpandNETStandardFacades /> to it might resolve that issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EWSoftware/SHFB/issues/599#issuecomment-388948789, or mute the thread https://github.com/notifications/unsubscribe-auth/AKVzKGnjT6WnEk93QZ2pCjZY-CH8CYiQks5tyeaUgaJpZM4T4NyR .

AshwinKamathB commented 6 years ago

First one I am sure it’s a defect same solution if I build it will pass and if I build shfbj project it won’t pass I don’t think with in a faction of sec Nuget source not reachable possible in all the build.Is there any where we need to set package source for shfbj project.

You can close if issue is not related to your team.

On Fri, 11 May 2018 at 2:42 PM, Eriawan Kusumawardhono < notifications@github.com> wrote:

@AshwinKamathB https://github.com/AshwinKamathB

Your issue is actually different things, and it's not related to Sandcastle (SHFB) at all.

First, separate the problems. The first error: MRefBuilder : error : Unresolved assembly reference: Czm.Czi.DeviceGateway.DTO (Czm.Czi.DeviceGateway.DTO, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) required by Czm.GenericDevice.Listener.Interfaces [E:\GD\Main\Runtime\Release\Listener\netstandard2.0\PackageDocumentation\Documentation\Working\GenerateRefInfo.proj]

is caused by the fact that the nuget source isn't reachable by MSBUILD.

This error: Encountered conflict between 'Reference:C:\Users\kjnrc1.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\ref\System.Xml.ReaderWriter.dll' and 'Reference:C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\System.Xml.ReaderWriter.dll'. Choosing 'Reference:C:\Users\kjnrc1.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\ref\System.Xml.ReaderWriter.dll' because file version '4.6.25519.3' is greater than '4.6.25507.1'.

is basically caused by referencing .NET Standard dll (including .NET Standard targeted nuget packages) within legacy .NET Framework projects. I mean legacy because .NET Standard/.NET Core project is using SDK format in the header of the csproj:

<Project Sdk=""Microsoft.NET.Sdk">

instead of:

<Project Toolsversion="15.0" ... >

To solve this, you should add inside your csproject. This is the current behavior of MSBUILD when resolving non-SDK projects that have references to .NET Standard libraries. For example: Microsoft/msbuild#2527 https://github.com/Microsoft/msbuild/issues/2527

@EWSoftware https://github.com/EWSoftware could we close this issue instead? Based on my explanation above, IMHO it's not related to SHFB at all.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/EWSoftware/SHFB/issues/599#issuecomment-388308289, or mute the thread https://github.com/notifications/unsubscribe-auth/AKVzKB2by-en3b8MtKVK3rlgcVwlDIWyks5txVXzgaJpZM4T4NyR .

EWSoftware commented 6 years ago

@AshwinKamathB: As I've asked for twice: Can you send me an example that I can build to duplicate the issue? Without one, I can't do anything.

AshwinKamathB commented 6 years ago

Dear sir,

I can give you a sample project but where to push nuget package.You won’t have access rt to our local repository? Do you have any test repository available from there I will refer in my project.

On Tue, 15 May 2018 at 6:39 AM, Eric Woodruff notifications@github.com wrote:

@AshwinKamathB https://github.com/AshwinKamathB: As I've asked for twice: Can you send me an example that I can build to duplicate the issue? Without one, I can't do anything.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EWSoftware/SHFB/issues/599#issuecomment-389010291, or mute the thread https://github.com/notifications/unsubscribe-auth/AKVzKIFeBCvkk7l6M6ZMbLrC474DWhNjks5tyiq_gaJpZM4T4NyR .

EWSoftware commented 6 years ago

It's using a local repository right? Just tell me how to set it up so the project finds it locally.

AshwinKamathB commented 6 years ago

Perfect will give in another 10 hrs. On Tue, 15 May 2018 at 8:25 AM, Eric Woodruff notifications@github.com wrote:

It's using a local repository right? Just tell me how to set it up so the project finds it locally.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EWSoftware/SHFB/issues/599#issuecomment-389026900, or mute the thread https://github.com/notifications/unsubscribe-auth/AKVzKEoq08PgbtXHFNSlNzbZIyPI0CzCks5tykOvgaJpZM4T4NyR .

AshwinKamathB commented 6 years ago

Shared the file using Google drive

On Tue, May 15, 2018 at 8:28 AM, Ashwin Kamath ak311988@gmail.com wrote:

Perfect will give in another 10 hrs.

On Tue, 15 May 2018 at 8:25 AM, Eric Woodruff notifications@github.com wrote:

It's using a local repository right? Just tell me how to set it up so the project finds it locally.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EWSoftware/SHFB/issues/599#issuecomment-389026900, or mute the thread https://github.com/notifications/unsubscribe-auth/AKVzKEoq08PgbtXHFNSlNzbZIyPI0CzCks5tykOvgaJpZM4T4NyR .

AshwinKamathB commented 6 years ago

I have already shared the example project also this issue still exist

EWSoftware commented 6 years ago

I replied to your e-mail. It was rejected by the virus scanner. I replied and told you to strip out the binaries and send just the code and projects so I could build it myself. You didn't respond to that last e-mail. If you can do as I asked, I'll take a look at the example you send.