Quantcast
Channel: Sandcastle Help File Builder
Viewing all 2184 articles
Browse latest View live

New Post: Where should I insert my custom XSL Transformation

$
0
0
You may not want to, but writing a plug-in is the appropriate solution. The other alternative is to manually add it to the project template but you'll have to do that with each new release and it would run for every project which is undesirable. The plug-in will allow you to add it to just the projects that need it. The new plug-in project templates give a good head start so it shouldn't take that long given the simplicity of the task at hand. See the ScriptSharpPlugIn for an example as it's close to what you want to do.

Eric

New Post: Where should I insert my custom XSL Transformation

$
0
0
Eric, I really think we should add a way to override TransformManifest.proj targets. Why not add a simple import targets statement at the end of the document that would load project specific targets? I wouldn't cost mush.

Adding a single transformation, especially as simple as mine, shouldn't require writing a cs class and creating a winform with all the configuration xpathnavigator hassle. Also, if I would create a plug-in, I wouldn't ever want to re-use it.

I think what I'll do is add a msbuild task in the BeforeBuildHelp target, that'll ensure the current version of TransformManifest.proj has the import statement and define my targets override in a project specific file.

I understand the plug-in logic, but when it's one time use only/not to be redistributed, small, I think that's an overkill.
Why couldn`t we specify target tasks for all the individual build steps?

Thanks

New Post: Where should I insert my custom XSL Transformation

$
0
0
Something around those lines:
<Import Project ="$(WorkingFolder)\TransformManifest.targets" Condition="Exists('$(WorkingFolder)\TransformManifest.targets')"/>
The only thing that would that would left to do is to copy TransformManifest.targets when in project folder to the working folder.

Correct me if I'm wrong.

New Post: Where should I insert my custom XSL Transformation

$
0
0
The plug-in architecture exist to handle this. Sorry, but that is not going to change. If it's just a one-off, it doesn't need to be configurable, just hard code everything.

Eric

Closed Unassigned: could not find a part of the path c:\...\fti\FTI_Files.json [35203]

$
0
0
could not find a part of the path c:\...\fti\FTI_Files.json

I get the above error when I use the search feature.
What info can I send to help get this resolved?
Comments: No further response from OP. If it wasn't just missed files, feel free to reopen and provide more details.

Closed Unassigned: MSBuild builds SHFB project file before Documentation Source [35154]

$
0
0
I have added a new Documentation Source to my SHFB project. When MSBuild runs (from TFS) I now get an error:

_Built $/xxx/Sandcastle Help File Builder/MyProject.shfbproj for default targets.
SHFB: Project assembly does not exist: C:\Builds\1\xxx\bin\MyNewAssembly.dll_

_Built $/xxx/MyNewAssembly/MyNewAssembly.csproj for default targets._

Looking at the MSBuild log file in detail I can see that the SHFB project does indeed build before m new assembly and hence the error. I had this problem before which I solved by setting the Advanced Setting > __MSBuild Mulit-Proc__ to false. I checked the build and this setting is still false.

Is there anything else I can do to ensure all of the Documentation Sources build _before_ the SHFB project builds?
Comments: No further response from OP. If you can provide an example as requested, feel free to reopen the issue.

Closed Unassigned: Build warnings since migration to 2014.2.15.0 [35129]

$
0
0
Since I have updated to the Version 2014.2.15.0, I receive a lot! of build warnings in my solution.

Release | x86
0 error(s), 14289 warning(s)
$/trunk/Source/Client.sln - 0 error(s), 923 warning(s), View Log File
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [T:DialogTestView] MSDN URL not found for target 'T:System.Windows.FrameworkElement'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [T:DialogTestView] MSDN URL not found for target 'M:System.Windows.FrameworkElement.ShouldSerializeTriggers'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [T:DialogTestView] MSDN URL not found for target 'P:System.Windows.FrameworkElement.Triggers'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [T:DialogTestView] MSDN URL not found for target 'T:System.Windows.FrameworkElement'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [T:DialogTestView] MSDN URL not found for target 'M:System.Windows.Controls.Control.ToString'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [T:DialogTestView] MSDN URL not found for target 'T:System.Windows.Controls.Control'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
...
$/trunk/Source/Server.sln - 0 error(s), 13366 warning(s), View Log File
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [Methods.T:Configuration] MSDN URL not found for target 'T:System.Object'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [Methods.T:Configuration] MSDN URL not found for target 'T:System.Object'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [Methods.T:Configuration] MSDN URL not found for target 'T:System.Object'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [Methods.T:Configuration] MSDN URL not found for target 'M:System.Object.Finalize'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
C:\Program Files (x86)\EWSoftware\Sandcastle Help File Builder\SandcastleHelpFileBuilder.targets (38): BuildAssembler : warning : ResolveReferenceLinksComponent: [Methods.T:Configuration] MSDN URL not found for target 'T:System.Object'. [C:\Builds\bin\Working\BuildReferenceTopics.proj]
...

In the previous Version 1.9.8.0 there wasn't warnings on the solution.
Comments: No further response from OP. If you can provide an example as requested, feel free to reopen the issue.

New Post: Where should I insert my custom XSL Transformation

$
0
0
FYI, I've implemented the import and a simple r-o copy of my targets file to the working folder and it works like a charm.
I've also added a task that adds the import element conditionally to follow SHFB updates.

It worth the effort as I might override TransformManifest targets in other projects, but still I fail to see the need of an overcomplicated plug-in.
Granted it would have been built-in, my action would have taken 5 lines of code only.

I'm sorry we disagree on this and I humbly invite you to reconsider.
At worst, why not add other event menus in SHFB such as the Pre and Post build event?
This arise the question: Why have pre and post build events if we're so plug-in driven?

I couldn't hardcode TransformManifest.proj in install folder as I am managing 5 SHFB projects.
I think we should be able to customize/overload all core operations on a per project basis
meaning without having to modify SHFB installation. E.g.: change a sandcastle transformation file for a single project.

This is just a friendly opinion.

New Post: Auto-Expand Namespace

$
0
0
Just want to mention, I would've needed it also. Couldn't there be a setting?

New Post: Changing the display of default Namespace name

$
0
0
You could do as I did, insert a name mapping xsl transformation before the execution of the transform manifest project. Related post.

New Post: Suggestion: Customizing XSL Transformation Per Project

$
0
0
Why not add a way to change the transform main_sandcastle.xsl file path so it points inside the project folder instead of the static reference to the install folder?

Why not an additional item under the Transform Args project properties tab?

New Post: Suggestion: Customizing XSL Transformation Per Project

$
0
0
I implemented BuildReferenceTopics target override (As I did for TransformManifest... discussed in another topic) then in a BeforeBuildReferenceTopics target override I:
1-copy the presentation style to the working folder
2-Copy my overrides found in my SHFB prohect folder
3-Change the main_sandcastle.xsl location (in the custom sandcastle.config) to the working folder.

This allows me to override the "utilities_reference.xsl" file for instance, while benefiting of the new sandcastle presentation style updates.

Hard-coding wasn't an option in my case. The reason is that I have multiple SHFB projects using the same presentation style in different ways. Also, I report to someone meaning I can`t use sloppy workarounds.

New Post: What does topic branding means exactly?

$
0
0
What does topic branding means exactly? What's done in there?

New Post: What does topic branding means exactly?

$
0
0
MS Help Viewer supports unbranded content and self-branded content. For unbranded content it will apply the default MS Help Viewer Style (Microsoft copyrighting and logo etc.) which is what you see when looking at Microsoft content in the help viewer. For self-branded content such as that generated by Sandcastle, it passed it through relatively unchanged apart from target URL fix ups. Unbranded content was never really supported by Sandcastle so it was a largely unnecessary step. The next release completely removes it so it's no longer relevant. The branding component is now considered obsolete and will be removed at some point in the future.

Eric

Created Unassigned: TOC incorrect for explicit interface from separate assembly [35208]

$
0
0
Using C# Visual Studio 2012: I have an interface defined in a third-party assembly, as illlustrated below. This interface contains method GetID(). When I use explicit interface implementation, the table of contents, index, and topic header will refer to the GetID() method as "ITestInterface." rather than "ITestInterface.GetID".

When the interface and the derived class are contained in the same assembly, I don't have this problem. Is this a known issue, or am I not doing something correctly?

```
// assembly containing interface
namespace testApp
{
/// <summary>
/// Interface for testing SHFB
/// </summary>
public interface ITestInterface
{
/// <summary>
/// Get The ID
/// </summary>
/// <returns>ID</returns>
uint GetID();
}
}// namespace testApp
```
```
// test program
namespace testApp
{
/// <summary>
/// Test program for documentation of explicit interface implementation
/// </summary>
public class TestProgram : ITestInterface
{
/// <summary>
/// Main entry point
/// </summary>
/// <param name="args"></param>
static void Main(string[] args)
{
}

#region ITestInterface Methods
/// <summary>
/// Get the ID
/// </summary>
/// <returns>ID</returns>
uint ITestInterface.GetID()
{
return 0;
}// GetID
#endregion
}// class TestProgram
}// namespace testApp
```

New Post: Plug-Ins vs Components

$
0
0
Am I right saying that the only difference between plug-ins and components is that components specialize in topic/"reflection info" transformation and handling while plug-ins touch everything else. E.g.: TOC which is not topic themselves, external utilities...?

New Post: Plug-Ins vs Components

$
0
0
I said "reflection info", but can a component affect the reflection file or is it too late at the moment the component executes?

I found that components are put in sandcastle.config prior to the XSL Transformation one. Is this systematic?

New Post: Plug-Ins vs Components

$
0
0
Plug-ins can run in any build step either before, after, or replacing the step entirely. Build components are limited to running within BuildAssembler during the BuildConceptualTopics and BuildReferenceTopics build steps. They act upon the reflection data, comments, and other info which is merged into a topic that is ultimately transformed into HTML.

Eric

Created Unassigned: Only Create one *cs file [35211]

$
0
0
My C# project have about 10 cs file, when i run Sandcastle Help File Builder only 1 file create to help file. I check my XML file, it have 10 cs file xml data. Do I loss some setting? or My XML is not correct?

Commented Unassigned: Only Create one *cs file [35211]

$
0
0
My C# project have about 10 cs file, when i run Sandcastle Help File Builder only 1 file create to help file. I check my XML file, it have 10 cs file xml data. Do I loss some setting? or My XML is not correct?
Comments: ** Comment from web user: EWoodruff **

Bear in mind that the number of files has no bearing on the number of entries in the help file. What gets documented are classes and members. In addition, only public classes and members are documented by default. If you want to see private and internal members, enable the options to document them in the Visibility category of project properties.

Viewing all 2184 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>