Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hard-to-diagnose "No metadata is generated" #1686

Closed
matkoch opened this issue May 23, 2017 · 14 comments
Closed

Hard-to-diagnose "No metadata is generated" #1686

matkoch opened this issue May 23, 2017 · 14 comments
Labels
dotnet Generate .NET API reference docs

Comments

@matkoch
Copy link

matkoch commented May 23, 2017

In relation to #165.

Even though I have --logLevel Verbose I cannot tell why the project is being skipped with Warning:No metadata is generated for XXX..

@vicancy vicancy added dotnet Generate .NET API reference docs documentation labels May 24, 2017
@vicancy
Copy link
Contributor

vicancy commented May 24, 2017

  1. Better logging
  2. Troubleshooting guide

@ThadHouse
Copy link

Is there anything else we can try rather than just install MS Build Tools 2015? I have multiple systems that have both 2015 and 2017 installed, and still can't generate metadata. I don't think that is the only dependency, or maybe something in VS 2017 is overriding something in the GAC causing docfx to fail.

@matkoch
Copy link
Author

matkoch commented May 26, 2017

@ThadHouse in my case I was targeting multiple target frameworks. In case you have the same, you need to specify them in your docfx.json as described here: #1254 (comment)

@ThadHouse
Copy link

ThadHouse commented May 26, 2017

I'll double check that, but I think I've tried that before. I'm getting the error where no files are being returned by the MSBuildProject. But I'll try again. I might just end up putting a project.json back in my projects, because that does seem to actually work.

@matkoch
Copy link
Author

matkoch commented May 26, 2017

What do you have instead? I think I've read something about xproj not being supported. But not sure :)

@ThadHouse
Copy link

I'm using new VS 2017 csproj files, which have never worked for me in docfx, even though theyre supposed to.

@matkoch
Copy link
Author

matkoch commented May 26, 2017

Yes, for me that works. Public types/members? Maybe you can reference the project here?

@ThadHouse
Copy link

Yeah I've tried a ton of different things. Even example projects posted by both the docfx team, and other people that have posted issues don't work for me. Nothing related to the new csproj works for me.

@ThadHouse
Copy link

I was able to get it working on one of my machines (I don't know how...) However, AppVeyor still does not work for me, so something still is not right with the dependencies that are thought to be required.

@vicancy
Copy link
Contributor

vicancy commented May 31, 2017

Hi @ThadHouse , is it possible for you to share your project & AppVeyor settings for me to take a look?

@ThadHouse
Copy link

https://github.com/robotdotnet/WPILib-Docs/tree/metadatatest

Here's my repo that I have to generate the docs. The runBuild.ps1 script downloads the latest version of docfx, clone my repos, and then attempt to run docfx. The appveyor settings are in appveyor.yml.

https://github.com/robotdotnet/FRC-Utilities

This is probably my easy repo to test metadata generation if you want to try manually, since there isn't a lot in the repo, and only 2 targetplatforms.

@ThadHouse
Copy link

https://ci.appveyor.com/project/robotdotnet/wpilib-docs/build/master-35-qxdglprl

Here's also the latest build attempt on AppVeyor

@vicancy
Copy link
Contributor

vicancy commented Jun 7, 2017

Hi @ThadHouse According to https://github.com/robotdotnet/FRC-Utilities you are targeting multiple frameworks, could you add

"properties": {
                "TargetFramework": <one_of_your_framework>
            }

to your metadata section?

dlech added a commit to dlech/docfx that referenced this issue Jun 7, 2017
MSBuildWorkspace.OpenSolutionAsync() and MSBuildWorkspace.OpenProjectAsync() do not give any notification that loading a solution or project failed. However, there is a WorkspaceFailed event that we can use to be notified when there is a problem. This logs the diagnotic information from this event to help the user troubleshoot.

Related:
* dotnet/roslyn#19978 (comment)
* dotnet#1686
* dotnet#1708 (comment)
vicancy pushed a commit that referenced this issue Jun 8, 2017
MSBuildWorkspace.OpenSolutionAsync() and MSBuildWorkspace.OpenProjectAsync() do not give any notification that loading a solution or project failed. However, there is a WorkspaceFailed event that we can use to be notified when there is a problem. This logs the diagnotic information from this event to help the user troubleshoot.

Related:
* dotnet/roslyn#19978 (comment)
* #1686
* #1708 (comment)
@vicancy vicancy closed this as completed Jun 8, 2017
@ThadHouse
Copy link

Neither the TargetFramework nor the updated build tools requirement help this build on appveyor. Also tested the new logger function, and all it says is "Failed to parse file", so its not very helpful.

vicancy pushed a commit that referenced this issue Jun 15, 2017
MSBuildWorkspace.OpenSolutionAsync() and MSBuildWorkspace.OpenProjectAsync() do not give any notification that loading a solution or project failed. However, there is a WorkspaceFailed event that we can use to be notified when there is a problem. This logs the diagnotic information from this event to help the user troubleshoot.

Related:
* dotnet/roslyn#19978 (comment)
* #1686
* #1708 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dotnet Generate .NET API reference docs
Projects
None yet
Development

No branches or pull requests

3 participants