MadCap Software Forums

The target build process fails for me when my project resides on a network. Has anyone else had this issue?

"My Project" files at my current company are mapped to a share drive for synchronization and backup purposes so the writers here are not accustomed to working on local copies (in case someone wants to ask why in heck the project is not local ).

It is only the build process that fails (one observation is that the user folder is not created during the target build process on the server- different than when the build is local...could that have something to do with the build process not finding the Windows user name that it is expecting to find because the server is remote? Could the build be failing at that point because it doesn't know what to do?)

What's the error message?

can I attach the build report? I don't see a way to do so but my eyes are crossed at this point

Normally if the build fails the error tab of the build screen appears automatically (and there's an option to save the report from there). If there's just a warning (e.g., it couldn't resolve a link to an email address) then it'll announce that the build completed but with errors and the error tab won't appear automatically.

Yep - I know. I have a report because the build completed with errors. The output is unusable. Do you want to see the report? It's a list of "can't find the file path" errors, even though the topics exist right where Flare is looking. The one unique thing is that the target build is not creating the expected username folder as it should.
MC support, my IT dept. and I have been pulling our hair out about this one.
According to MC, a user should be able to successfully work on Flare projects that are remote. But, for me in this company environment, the build process doesn't work.

I build projects on my local computer because A) I'm the only author, B) it's faster, and C) there are apparently some issues with the index when building to a networked drive.

That said, I used to build to a mapped network drive and there weren't any problems building, but that was back in version 2. What version are you running and I'll see if I can replicate the issue. Did you use the standard Windows process for mapping the drive? And did you map to the DNS name of the server or using the IP address?

IF you try a differnent or a sample project does it build on the network?

Nope - tried that. Did a test with my current project as well as a sample project (all Flare defaults). Same build errors (Failed to resolve link: file://path to my folder/<topic.htm>
Subsystem: Compiler

The latest thought is that I need to add the machine name and IP address of that network box to your hosts file. Not something to do with Flare itself. Will post the resolution if this is it.

Still entertaining other ideas!

Can you copy a file to the target network share? Maybe it is a permissions problem. IT may have changed things without telling the affected users, they do that often and seem to enjoy it as well.

Yes, I can copy...which aslo means I can set a Publishing target on the network share when I build locally. Sounded "permissionish" to me, too. Got an IT dude chained to the issue so we'll see how long it takes to resolve it.

So if I understand correctly, you have the Windows "Documents and Settings" folder structure mapped to a network drive rather than locally, and you've got everyone using a Flare project that is in everybody's My Documents folder in that structure - is that correct?

If so, one thing you might try is copying the Flare project out of the My Documents structure and putting it in a folder at the root of the network drive, then try making a build.

Basically, I don't trust Microsquish's "My Documents" folder mess as far as I can throw downtown Toronto at the best of times: mapping it to a non-local drive sounds like the computing equivalent of mass suicide. If you stick to something with a consistent and much shorter path you'll probably have fewer problems.

I agree and I haven't tried a build from a project that is residing at the root of the network drive. It's all an MS dfs hairball and my suspicion is that the fix (temporary) is to make sure that the network machine name/IP address is added to my hosts file. Since I am the lead (crash test dummy) on this implementation of Flare, I need to make sure that the writers who will be working on their Flare projects don't have crazy network stuff getting in the way of their work. They are supposed to be able to trust that their folders on the shared drive are stable, back up, etc. and not have to do some workaround to get a Flare project to build without errors...sigh.

I have no issues with MS as long as the OS/Apps do what I want...it's all about me, of course....but it's when they don't OR someone has set stuff up incorrectly and thinks that blaming MS will take the focus off the real issue (the Work Blame Structure, in project management-speak) when I get fired up.


__________________________________
Moderator note (docguy): Duplicate message removed. 7/2/09.

Well, saving the file outside of My Documents didn't work either (on the shared drive). Still entertaining other options

IS the path name a Drive letter like N:\my work folder or a UNC Path like \\NetworkName\share\Folder?

if Its a unc, try a drive letter....

ltnunes wrote:Well, saving the file outside of My Documents didn't work either (on the shared drive). Still entertaining other options

Not sure if mine is the same problem, or a variation... I want the project saved on a network drive which I can access remotely - or at least from another pc, so created folder on network drive, set up permissions etc, then created project in that folder. Mapped folder as drive T: on main pc and on notebook, so path to project file is T:\projectfolder\projectfile.fprj.

If I make changes to any content, or create topics, or create or modify any other kind of project file, they don't show up in Flare's content explorer until and unless Flare is closed down and restarted.... which is a nuisance... there doesn't seem to be any way of refreshing the list from within the program.

Created a new target - html help - and this appeared straight away in the project organizer.... and the build went through with no errors, but when I opted to view the finished build, the TOC had the correct title, but the opening topic said that navigation to the web page was cancelled and none of the links worked.... and even if Flare is closed and reopened, I cannot view the chm.... but if the file is copied to the local machine, everything works fine, so the build itself hasn't failed.

panda wrote:Not sure if mine is the same problem, or a variation... I want the project saved on a network drive which I can access remotely - or at least from another pc, so created folder on network drive, set up permissions etc, then created project in that folder. Mapped folder as drive T: on main pc and on notebook, so path to project file is T:\projectfolder\projectfile.fprj.

If I make changes to any content, or create topics, or create or modify any other kind of project file, they don't show up in Flare's content explorer until and unless Flare is closed down and restarted.... which is a nuisance... there doesn't seem to be any way of refreshing the list from within the program.

Can't help you with this...Flare works on our network drives.

However, this:

Created a new target - html help - and this appeared straight away in the project organizer.... and the build went through with no errors, but when I opted to view the finished build, the TOC had the correct title, but the opening topic said that navigation to the web page was cancelled and none of the links worked.... and even if Flare is closed and reopened, I cannot view the chm.... but if the file is copied to the local machine, everything works fine, so the build itself hasn't failed.

This is a result of a Microsoft security patch for HTML Help (CHM files) that prevents them from working properly on a network drive unless you make a particular registry entry. Here is information and the registry workaround. However, instead of worrying about this registry workaround, I simply copy/paste my help file to my desktop if I really want to review it. We only use the workaround for our customers who want to host the help file on a network location.

[quote="AndrewThis is a result of a Microsoft security patch for HTML Help (CHM files) that prevents them from working properly on a network drive unless you make a particular registry entry. Here is information and the registry workaround. However, instead of worrying about this registry workaround, I simply copy/paste my help file to my desktop if I really want to review it. We only use the workaround for our customers who want to host the help file on a network location.[/quote]

Oh, thank you for this! For me, I'm happy to copy the result to the local drive for checking, but it's really useful to know for customer installation. HTML would not be my first choice, but for various reasons it may be what the client chooses.

You actually are describing two separate issues here, neither of which is strictly a Flare problem.

panda wrote:I want the project saved on a network drive which I can access remotely - or at least from another pc, so created folder on network drive, set up permissions etc, then created project in that folder. Mapped folder as drive T: on main pc and on notebook, so path to project file is T:\projectfolder\projectfile.fprj.

If I make changes to any content, or create topics, or create or modify any other kind of project file, they don't show up in Flare's content explorer until and unless Flare is closed down and restarted.... which is a nuisance... there doesn't seem to be any way of refreshing the list from within the program.

What this sounds like is network latency. Sometimes the content on mapped drives doesn't update right away. You should be able to refresh by hitting F5, but yes it is a pain.

Created a new target - html help - and this appeared straight away in the project organizer.... and the build went through with no errors, but when I opted to view the finished build, the TOC had the correct title, but the opening topic said that navigation to the web page was cancelled and none of the links worked.... and even if Flare is closed and reopened, I cannot view the chm.... but if the file is copied to the local machine, everything works fine, so the build itself hasn't failed.

This is the nature of CHM at the present time, and has to do with a Microsoft security change. Basically, a number of years ago a security vulnerability in CHMs was found, and rather than actually fix the vulnerability Microsoft decided (as usual) to simply block them from running over a network altogether. By default, CHMs only work locally now. There is a registry change you can make to restore the network functionality, but every one of your users would need that change if you want to have them access a CHM over a network (and customer IT departments usually don't like it when you start disabling security settings) so realistically the CHM format is a local-only format now.

KevinDAmery wrote:You actually are describing two separate issues here, neither of which is strictly a Flare problem.

No, accepted... just dealing with something that doesn't manifest itself - at least, not in this way - with other applications I use.

What this sounds like is network latency. Sometimes the content on mapped drives doesn't update right away. You should be able to refresh by hitting F5, but yes it is a pain.

Even more so because my F5 didn't work... have since discovered that it's a two-handed op involving holding down another key, and yes that does work now... can do it single handed by changing the display of Flare's Content Explorer twice (collapsing and uncollapsing not effective), which is also a pain... might just put in a feature request for refresh to be on the right click menu in the project and content explorer panes.

This is the nature of CHM at the present time, and has to do with a Microsoft security change. Basically, a number of years ago a security vulnerability in CHMs was found, and rather than actually fix the vulnerability Microsoft decided (as usual) to simply block them from running over a network altogether. By default, CHMs only work locally now. There is a registry change you can make to restore the network functionality, but every one of your users would need that change if you want to have them access a CHM over a network (and customer IT departments usually don't like it when you start disabling security settings) so realistically the CHM format is a local-only format now.

Our software is mostly run locally, so that is not a disadvantage in itself, but I am concerned that Microsoft seem to have abandoned it altogether. My client prefers the single file format and the fact that MadCap branding doesn't pop up all over the place - or inappropriate links to developer forums

Thanks, Kevin.

Here's what Microsoft has to say about it:

http://www.microsoft.com/technet/securi ... 5-026.mspx

KevinDAmery wrote:Here's what Microsoft has to say about it:

http://www.microsoft.com/technet/securi ... 5-026.mspx

Thanks... I think someone else wrote something about MS choosing prevention rather than cure. But at least I know now what it is.

Oh.... and thanks too for 'network latency'... it sounds so much more IT than Net Lag

We use a mapped network drive for all our projects and the builds work fine, even the command line batch builds OK.

Panda, the reason u cant view the chm correctly on a network is coz of an IE security restriction. You can change a registry setting which will allow it to work.
The registry change is :
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001

Back to the original issue.....
I have found that this remote build issue is only happening with one laptop so there's something in that machine's configuration that's fighting with the Flare build. It fails to create the user folder in the output path, if that's a clue.

I found numerous "fixes" for this issue, but none of them worked for me. The project was in a subfolder with a period in the folder name, to keep the subfolder at the top of the parent folder. No problem generating HTML or PDF, but CHM Target didn't like that. After a few days of trying "What about this?" and "What about that?" I decided to remove the period. Yep, that was it. <heavy_sigh>