locked
Deploying Help Viewer 2.0 Content

    Question

  • We sell components that customers use in their .NET applications.  When our components are installed, we install our own help content (generated via Sandcastle) so that our customers may view content from Visual Studio 2010 (via Help Viewer 1.0), and this works beautifully.

    We began testing things with the Visual Studio 11 Beta (in the Windows 8 Consumer Preview), and ran into some problems.  Long story short, it looks like we are able to install our content using HlpCtntMgr (which appears to be the replacement for HelpLibManager).  However, any time we try to view one of our topics, the tab which would show the content hangs saying "Loading..." indefinitely.  Do we need to wait for a new version of Sandcastle to produce the content in an updated format for Help Viewer 2.0?  If not, what would be the best way to go about troubleshooting this?

    Additionally, we noticed that HlpCtntMgr shows a prompt about our code signing certificate, which makes it impossible to install the content silently (from an installer).  Is there anything that can be done to get this to behave like HelpLibManager does?

    Wednesday, March 28, 2012 6:38 PM

Answers

  • Hello Abram,

    Yes HlpCtntMgr is the replacement for the command line components of HelpLibManager.

    For your first question, I know we have had some reports of this behavior.  The last time we investigated it the content was referencing a css that was not in the MSHC.  You might check your references in your content to verify they are all present in the mshc.  If everything looks correct it is probably faster to file a connect bug and attach the mshc and msha.

    For your second question, have you tried using the /silent parameter on the command line?  That should prevent any UI from being shown to the user.

    • Marked as answer by Abram Thursday, March 29, 2012 7:22 PM
    Wednesday, March 28, 2012 11:56 PM
  • Abram,

    I am not able to reproduce this on my machine.  For me when I install a signed cab with /silent the install succeeds.  I did notice however that if the command window is not elevated the install will fail.  Is it possible this is what you are seeing?

    If this isn't the issue, can you put the command line in a batch file and echo %ERRORLEVEL% after?  I am curious what the exit code is you are getting.

    - Jason

    • Marked as answer by Abram Monday, April 02, 2012 12:32 PM
    Friday, March 30, 2012 10:41 PM

All replies

  • Hello Abram,

    Yes HlpCtntMgr is the replacement for the command line components of HelpLibManager.

    For your first question, I know we have had some reports of this behavior.  The last time we investigated it the content was referencing a css that was not in the MSHC.  You might check your references in your content to verify they are all present in the mshc.  If everything looks correct it is probably faster to file a connect bug and attach the mshc and msha.

    For your second question, have you tried using the /silent parameter on the command line?  That should prevent any UI from being shown to the user.

    • Marked as answer by Abram Thursday, March 29, 2012 7:22 PM
    Wednesday, March 28, 2012 11:56 PM
  • Thanks for the very speedy reply!

    For the first issue:

    It looks like you hit the nail on the head.  After digging into it a bit more, it seems there were some CSS files referenced by Sandcastle that are used for other help runtimes ("ms-help://Hx/HxRuntime/HxLink.css").  Since we are using the VS2005 presentation style, I removed these by commenting-out the link tag for the HxLink.css files from the following files under the Program Files (or "Program Files (x86)" for 64 bit systems) directory:

    • EWSoftware\Sandcastle Help File Builder\Templates\VS2005.xsl.
    • Sandcastle\Presentation\vs2005\transforms\main_conceptual.xsl
    • Sandcastle\Presentation\vs2005\transforms\utilities_reference.xsl

    Even though doing this did get it past the hang, the content has some rendering issues.  For example, instead of "public enum MyEnum", it is missing the spacing in Help Viewer 2.0 only, and shows as "publicenumMyEnum".  It still looks fine in Help Viewer 1.0.  It also seems worth noting that we are not generating MSHelp2 content from our SHFB project, but I imagine this would not be a great workaround if we were.

    We also now see a JavaScript error saying "Access is denied" every time we open a topic.  The URL for it looks like: ms-xhelp:///?method=asset&id=scripts\CommonUtilities.js&package=[MyMshcFileName]&topiclocale=EN-US (where [MyMhscFileName] is the name of our mshc file, of course.)

    I will dig into this a little more and post back about any new findings.


    For the second issue:

    Our installer already uses the /silent switch, but it fails to install the content with the VS11 beta.  If we remove the /silent switch, we see a dialog that says:

    Security Alert

    The content has been signed by using a certificate issued to [our company name].

    Do not install this content unless you trust its source.  The content publisher is Go Daddy Secure Certification Authority.

    Do you want to continue?

    [View certificate] [Yes] [No]

    It seems clear that it fails to install silently because of this security alert.  We do not get any sort of alert like this with the exact same msha and cab files when installing for HelpViewer 1.0.

    Thursday, March 29, 2012 3:10 PM
  • I am following up on the first issue again.  The JavaScript errors are coming from the CommonUtilities.js file that ships with Sandcastle.  Line 170 (reads "if (rules == null) rules = sheet.rules;") is the one that is throwing the access denied exception, which prevents it from loading the branding and presentation styles entirely.  This is probably why the words in the source examples are rendering without space between each other.  At this point, the best thing to do is probably to just open a connect bug for each issue.

    Thursday, March 29, 2012 7:04 PM
  • Abram,

    I am not able to reproduce this on my machine.  For me when I install a signed cab with /silent the install succeeds.  I did notice however that if the command window is not elevated the install will fail.  Is it possible this is what you are seeing?

    If this isn't the issue, can you put the command line in a batch file and echo %ERRORLEVEL% after?  I am curious what the exit code is you are getting.

    - Jason

    • Marked as answer by Abram Monday, April 02, 2012 12:32 PM
    Friday, March 30, 2012 10:41 PM
  • Thanks, Jason.  When I was testing with the batch file, I was not using an elevated command prompt.  When I ran that with elevated permissions (by bringing up the start menu, typing "cmd", and pressing ctrl-shift-enter), it worked just fine.  I suppose the issue then is that the /e switch isn't doing what I expected it to do.  ^_^

    Thanks again!

    Monday, April 02, 2012 12:32 PM
  • Just to follow-up with my last post, running HlpCtntMgr doesn't show anything for /e in the description, but I do see it documented at http://msdn.microsoft.com/en-us/library/hh496811%28v=vs.110%29.aspx.
    Monday, April 02, 2012 12:38 PM
  • Hello Abram,

    I faced with the same problem with Sandcastle and MS Help Viewer 2. Do you have some news about the issue?

    Thursday, April 05, 2012 5:59 AM
  • Unfortunately, no, not yet.  I opened a connect bug, but that seems to have been resolved as an external issue.  So the next thing I'll try doing is reporting it in Sandcastle's issue tracker on codeplex (when I return from my trip).
    Thursday, April 05, 2012 5:06 PM
  • I'll be taking a closer look at the new MS Help Viewer soon so that I can support it in SHFB.  From my first look, it appears that I'll only need to change the install/remove scripts and the related help library manager tool.  Regarding the style issues, another user, Don Fehr, has been working on a VS 2010 style which will work better than the existing Sandcastle VS2005 style as it is built to work with the new help viewer.  It'll be included in the next Sandcastle release which is not quite ready yet but should be out soon.

    Eric

    Thursday, April 05, 2012 7:28 PM
  • Great!  Thanks so much for following-up with this, Eric.

    -Abram

    Tuesday, April 10, 2012 2:38 PM
  • We are also seeing the same scripting error in Help Viewer 2.0 (but not earlier versions).  Specifically, this one mentioned above:

    "Access is denied" every time we open a topic.  The URL for it looks like:ms-xhelp:///?method=asset&id=scripts\CommonUtilities.js&package=[MyMshcFileName]&topiclocale=EN-US

    We're not generating the content using Sandcastle as they are older help template HTML files.  Was there a way to fix this explicitly?

    Thanks in advance.

    Saturday, December 15, 2012 3:18 AM
  • Sandcastle does contain a CommonUtilities.js file which was the cause of the problem.  Are you using it?  If so, the fix is in two parts.  The first is to wrap the for() loop in getStyleDictionary() with a try/catch.  The catch should do nothing and just ignore the error.  The second part is to put the following if() statement in the styleSheetHandler() function right after the assignment to the "sd" variable as shown:

        var sd = getStyleDictionary();

        // Ignore if not found (Help Viewer 2)
        if(typeof(sd['span.cs']) == "undefined")
            return;

    Eric

    Saturday, December 15, 2012 8:39 PM
  • Hi Eric,

    Thanks so much for your prompt reply.  I'm certain these scripts were copied from Sandcastle some time ago.  We've got the latest Sandcastle installed for another project, so perhaps I should simply refresh all of the script files for our VS2005 style?  Will give it a try unless a surgical update is recommended.

    Thanks again.

    Saturday, December 15, 2012 9:27 PM
  • Hi Eric,

    Replacing the CommonUtilities.js file with the one from the latest Sandcastle did the trick and fixed the script error.  I went ahead and replaced the other scripts too -- Checkboxmenu.js, dropdown.js.  I was wondering if it would fix the other issue we've been seeing that actually happens in both Help Viewer 1.1 and Help Viewer 2.0, though with different variations.  The syntax dropdowns at the top of each page render funny in 1.1 and don't render at all in 2.0.  I've attached a couple of screenshots in case you've seen this before.

    Saturday, December 15, 2012 10:31 PM
  • There were several issues with the presentation styles in Sandcastle caused by changes in the way Help Viewer 2.0 worked and it looks like you are running into them too.  There may have been some other fixes needed for Help Viewer 1.0 too though not as much as for Help Viewer 2.0.  My findings for Help Viewer 2.0 are detailed in this thread: http://social.msdn.microsoft.com/Forums/en-US/devdocs/thread/dbc08c20-c8c0-417a-abb8-102fea9444cf

    The latest release of Sandcastle contains the fixed presentation styles and build components so if you based your help topics on the format output by them, you may be able to locate the related sections and apply similar fixes to your topics.

    Another option would be to use the HTML to MAML converter to convert your topics to MAML and use Sandcastle/SHFB to build the help file.  That way it will contain the fixed presentation style automatically.

    Eric

    Sunday, December 16, 2012 7:27 PM
  • Hi Eric,

    Thanks again.  Indeed, I wish we could use Sandcastle for the portion of our product that's causing the issue.  We do use Sandcastle for our product documentation, but our product is, itself, a help generator and our customers insist on being able to author in HTML.  So, we host the native VS HTML editor inside a document window and let them edit snippets of HTML that we when place into our HTML "template" files.  These HTML template files are the ones we created long ago for Help 1.x  and Help 2.

    The piece at the top of our HTML files that seems to be responsible for the rendering issue in Help Viewer 1 and Help Viewer 2.0 is the following, in case you happen to recognize anything.  I've commented out various bits to see if there's something unused that's causing the problem, but to no avail.

    <body>
        <input type="hidden" id="userDataCache" class="userDataStyle" />
        <input type="hidden" id="hiddenScrollOffset" />
        <img id="collapseImage" style="display: none; height: 0; width: 0;" src="../icons/collapse_all.gif" alt="Collapse image" />
        <img id="expandImage" style="display: none; height: 0; width: 0;" src="../icons/expand_all.gif" alt="Expand Image" />
        <img id="collapseAllImage" style="display: none; height: 0; width: 0;" src="../icons/collapse_all.gif" />
        <img id="expandAllImage" style="display: none; height: 0; width: 0;" src="../icons/expand_all.gif" />
        <img id="dropDownImage" style="display: none; height: 0; width: 0;" src="../icons/dropdown.gif" />
        <img id="dropDownHoverImage" style="display: none; height: 0; width: 0;" src="../icons/dropdownHover.gif" />
        <img id="copyImage" style="display: none; height: 0; width: 0;" src="../icons/copycode.gif" alt="Copy image" />
        <img id="copyHoverImage" style="display: none; height: 0; width: 0;" src="../icons/copycodeHighlight.gif" alt="CopyHover image" />

    Monday, December 17, 2012 2:16 AM
  • In the thread I noted above, there's a link from Rob Chandler to a demo Help Viewer 2.0 file he created.  Your best bet is to take that, add a stripped down version of one of your topics to it and use that for testing.  You can then remove everything from your topic and start adding stuff back in until it breaks.  You can also compare the metadata to see if something is different or missing in your topic.  That's how I identified the issue with the Sandcastle presentations and came up with the fixes for them.

    Eric

    Monday, December 17, 2012 5:10 PM
  • Thanks Eric.  I'll do just that.  And the result of that should display fine in HV 1.x and HV 2.0 ?
    Monday, December 17, 2012 5:18 PM
  • If you find and fix the issues, it will work in both.

    Eric

    Tuesday, December 18, 2012 4:24 PM