API Filter problem

Oct 10, 2007 at 7:47 PM
I having difficulty using the API filter with a project for which I have already performed successful builds. The SHFB appears to be loading namespaces for about 15 seconds, then a message appears that reads:

Unable to build project to obtain API information. Please perform a normal build to identify and correct the problem.
Coordinator
Oct 10, 2007 at 8:15 PM
Can you send me the project and assemblies so that I can identify the problem? My e-mail address is in the About box and the footer of the pages in the help file.

Eric
Oct 11, 2007 at 5:44 PM
I am experiencing a similar issue using the 1.6 SHFB and Sept CTP. Building help from an asp.net 2.0 website generates the appropriate documentation, but the API Filter button fails with the same message xree is seeing. Interested in knowing what ideas you have to work around this issue and what constitutes a "normal" build.

Great tool, btw.
Coordinator
Oct 11, 2007 at 7:36 PM
If you can send me your project and the assemblies that will give me another test case. It's not actually failing in the build but the step after that which loads the tree view. As such, there is no workaround.

Eric
Oct 11, 2007 at 9:17 PM
unfortunately, some of the assemblies are proprietary and I cant send over this project. I'll see if I can repro with a easier test case and send that.
Coordinator
Oct 12, 2007 at 3:46 AM
I received the test case from Lee and was able to find and fix a couple of bugs. The fix probably will cover your case too. I'll release an update to the help file builder shortly after the CTP refresh is released.

Eric
Oct 18, 2007 at 10:46 AM
I have a similar problem, so I would be very interested in the update.
But let me also take the opportunity here to express my admiration and thanks for this great tool !
Coordinator
Oct 19, 2007 at 2:31 AM
If you are able and wouldn't mind sending me the project and the assemblies, it will give me another test case just to be sure that there isn't another problem. Thanks.

Eric
Oct 22, 2007 at 11:58 AM
I don't mind sending you the project, but you'll have to give me an e-mail address, because within codeplex.com I can't send you attachments... or can I ?
Erwin



EWoodruff wrote:
If you are able and wouldn't mind sending me the project and the assemblies, it will give me another test case just to be sure that there isn't another problem. Thanks.

Eric


Coordinator
Oct 22, 2007 at 4:11 PM
My e-mail address is in the About box in the GUI and in the footer of the pages in the help file.

Eric
Oct 22, 2007 at 4:58 PM
blushing from embarassement
Gee, do I feel stupid !
Aug 28, 2008 at 3:38 PM
Hi,

Firstly thank you for the great tool, secondly sorry for posting to an old thread...

I too have run across the Unable to build project to obtain API information. Please perform a normal build to identify and correct the problem error message, and Google lead me to this thread.

What happened for me was that I had refactored some code which was in a DLL that the main project referenced. The refactoring turned this single DLL into two DLLs. What I need to do to fix the problem was to ensure that all the DLLs created as a reference to the project were listed in the Sandcastle "Assemblies to Document" list.

(eg. I had a DLL which I split into two, DLL1 and DLL2. DLL2 relied on DLL1. When I referenced DLL2 in my web project, DLL1 was also added to the bin directory. I needed DLL1 to be in "Assemblies to document" to get rid of this error message)

So it wasn't a bug, it was user error on my part, but could I ask that the error message could be perhaps changed to:
Unable to build project to obtain API information, possibly because a referenced assembly is not in the "Assemblies to document" list. If all referenced assemblies are listed, then please perform a normal build to identify and correct the problem error message.

It's a little verbose, but, perhaps more concise.
Coordinator
Aug 28, 2008 at 5:11 PM
If you have assemblies that are dependencies but don't need to be documented, you need to add them to the Dependencies property.  That way, they will be found by MRefBuilder but won't appear in the help file.

Eric
Aug 29, 2008 at 8:42 AM
Ah - great -

Cheers for that, Eric.
Dec 1, 2008 at 6:30 PM
Hello Eric,

first of all, thank you for this great tool !

I have unfortunately the same issue : Unable to build project to obtain API information. Please perform a normal build to identify and correct the problem.

My project is composed of 1 DLL and the associated xml file.
There are 3 depedencies with GAC : System , System.Data and System.XML.

The project build with SHFB and generate a good HelpHtml2x. But, when I click in Namespaces or API Filter, this error occurs.

I precise that my ultimate goal is to exclude from my help doc some "private" namespaces. For the classes, add the <exclude/> works but the Namespaces appears in the menu on the left.
So I imagine I can exclude them in the Namespace tab but ... there is the error.

 

Do you have any idea of what could be the reason ?

I am sorry but I'm not authorized to send you my project. So I can only give you more informations if you need.

Thank you,

Best regards,

Pierre
Coordinator
Dec 1, 2008 at 8:23 PM
Edited Dec 1, 2008 at 8:24 PM
What version of the help file builder are you using?  If you cannot send me the assembly, can you at least set the help project's CleanIntermediates property to False, do a build, and send me the help project file and the content of the .\Working folder without the assemblies so that I can attempt to reproduce the problem using the intermediate files?

Eric
Dec 2, 2008 at 2:14 PM
Hello,

Thanks a lot for the really quick answer !!

I am not authorized to send my working folder, sorry.
I'm using the 1.7.0.0 version.

In fact, I understood that I can edit my shfb files and flag at false the isDocumented attribute of the NameSpaceSummaryItem.

Nevertheless, does it exist a way to exclude a namespace with a flag, an attribute in the XML linked to the DLL ? I'll save some times because in the first case, I have to manually update my shfb file. I can say a mistake but I think that NDoc allowed such a thing.

Thank you.
Best Regards,

Pierre
Coordinator
Dec 2, 2008 at 4:14 PM
Without an example that I can use to diagnose the problem, there isn't anything I can do.

Eric
Dec 3, 2008 at 9:45 AM
I imagine...

So I will try to find a solution.
But could tell me when this part of the XML tree is generated ?

<namespaceSummaries>
   <namespaceSummaryItem name="" isDocumented="False" />
   <namespaceSummaryItem name="MyClass1" isDocumented="True">
   <namespaceSummaryItem name="MyClass2" isDocumented="True">
</namespaceSummaries>
  

Because I presume that is in the NameSpaces menu so that would mean I already (months ago) accessed successfully there, but not anymore... :((

Thanks
Pierre
Coordinator
Dec 3, 2008 at 4:03 PM
Edited Dec 3, 2008 at 4:04 PM
That is created by the Namespace Summaries dialog.  However, unless it was a typo, the XML you posted isn't valid.  You're missing the self closing "/" on the second and third entries.  If not self closing, you need to add an end tag to each.  If you've been hand editing the project file, you may have made a mistake which could be contributing to the problem.  You could always try creating a new project and setting the properties via the GUI in the usual fashion.

Eric
Dec 3, 2008 at 4:30 PM
Right, I hand edit my XML. My real XML is ok.
I also try with a new project, generated from scratch with your GUI. Same result with my DLL.

I don't know if I was clear, but the help generation works great ! Everything is OK except the access to the Namespaces "menu".

I try to progress and contact you as soon as I have something to send to you.

Thanks for your time, I really appreciate !

Regards,

Pierre
Aug 27, 2009 at 5:46 PM

I'm getting this same error.  It looks like I may have inadvertantly unchecked all names spaces in the dialog.  Nothing seemed to unjam it so I added a new project source, did a build, re-checked one of my namespaces, then deleted the extraneous one.  This is the "namespace summaries" option in the "comments" section of the project properties.

Sep 1, 2010 at 5:41 AM

I'm getting this same error. Solution is: Delete all from <ApiFilter> in *.shfbproj file. It will help. If you scare to do it, just try to find in filters assemblies which not using any more in project and delete it.

Sep 24, 2010 at 9:51 PM

I'm sorry to be dredging up such an old topic, but I have just started to experience problems with the API Filter after using SHFB for quite a long time.  In one project in particular, I am getting the "Unable to obtain API Information. Please perform a normal build to identify and correct the problem." error when attempting to access the API Filter, although I am able to open API Filter a few times before receiving the error. I recreated this project a few times to see if I can pinpoint the problem, but no luck.  I add documentation sources, set the API Filter and am able to open it a couple of more times, but then I'll try again and I get the error. I can't make any rhyme or reason of it. I have checked the build log, but it doesn't list any problems.   I am using SHFB version 1.9.1 and have applied the recent Sandcastle patch.  I can send any files that would be helpful in troubleshooting this problem.  Thanks for any input.

Coordinator
Sep 28, 2010 at 8:22 PM

I wasn't able to duplicate it and I don't think I ever got a test case I could use to diagonse the problem.  If you can send me a small example that demonstrates the problem I'll look into it.  My e-mail address is in the About box in the GUI and in the footer of the pages in the help file.  The API filter does create a build log file in the %TMP%\SHFBPartialBuild folder (TMP is the value of the environment variable by that name).  However, my guess is that it's failing after the partial build while loading the reflection information so the partial build log file probably won't show a cause either.

Eric

 

Oct 14, 2010 at 8:54 PM

I have the same issue with the most recent version of Sandcastle:"Unable to build project to obtain API information. Please perform a normal build to identify and correct the problem."

It builds projects but will not allow me to open the API filter.

I am working on a C# project with Visual Studio 2010. It used to work fine in the same circumstances a bit more than a month ago. I resumed using Sandcastle yesterday: my first issue was that my normally reliable build would fail. I worked around that issue by changing a source reference from a project file to a reference to a .dll and a .xml file. I can now build but I am now encountering that new issue.

Coordinator
Oct 15, 2010 at 2:24 AM

I'm still waiting for somebody to send me an sample project that I can use to diagnose the issue.

Eric

 

Coordinator
Oct 26, 2010 at 12:36 AM

I received an example from Raymond.  The cause was a duplicate entry in the APIFilter section of the project for a namespace.  The workaround for the time being would be to remove the duplicate by editing the project in a text editor.  I wasn't able to get it to add the duplicate again.  For the next release, I've just added code to ignore the duplicate key and merge the information into the existing item if there are any child filters on the duplicate.

Eric

 

Nov 8, 2010 at 10:05 AM

I too managed to bump into this bug and was able to fix it by removing the duplicate entry from the project file. Thanks for tip EWoodruff.

The thing is that it keeps coming back when i save my project file. I think it must relate to the fact that one of my projects listed in the "Documented APIs" node also appears in the "Inherited APIs" node.

Jan 13, 2012 at 9:39 PM

I just got the same error when I unchecked both (global) and my namespace in the Namespace Summaries dialog.

To fix, I closed the program and edited the *.shfbproj project file. Seach for "NamespaceSummaryItem" and set all the isDocumented properties to "True".  All is back as it was when I reopen the project.