Compiling webhelp from Flare Working Natively in SharePoint

[tomjohnson1492]

In an inexpensive attempt to work off of a team drive, we're trying to run Flare off of a SharePoint document library. I can open and edit a Flare project that is located on SharePoint easy enough, but when I generate the webhelp, I receive the following error message:

nousersessionkey.jpg

It says "Internal error: There is no user session key for the specified logon session."

Anyone else get this message or know what it means? Can you run Flare off of SharePoint like this? Thanks,

Tom

[RamonS]

Why don't attach to TFS directly assuming that is what you use on the backend of SharePoint. I think you will get better results when you take the entire SharePoint layer out of the equation.

[KevinDAmery]

Or more simply... why not check all the Flare files out locally, do the build, then check everything back in? (The same way you would with a traditional source control system.)

[bobmoon]

we're trying to run Flare off of a SharePoint document library.

I'm not clear on what you're doing. Are you just using the SharePoint server as a storage location for the Flare project files, or are you using SharePoint to check the files in or out? How are you opening the project in Flare? Are you opening \\sharepoint\site\project.flprj?

Perhaps that error message indicates that Flare cannot determine who you are to create or manage the Output folder? Or perhaps the build is unable to create the Output folder structure on the server?

Bob

[tomjohnson1492]

We're just using SharePoint as a storage location, so yes, to open Flare, I'm basically going to \\sharepoint\site\project.flprj.

I was trying to generate the build to another SharePoint file location when I received the error. I don't have any issues generating it from my local machine.

Re checking files in and out, I haven't tried that, because I assumed there are so many related files that checking it in and out would be extremely tedious. Also, if I checked a file out, wouldn't all the other files need to be present to work on the file locally on my machine?

[bobmoon]

We're just using SharePoint as a storage location, so yes, to open Flare, I'm basically going to \\sharepoint\site\project.flprj.

If that's the case then I don't think that SharePoint is part of the problem. The server you're using just happens to also have SharePoint running on it.

I've never tried to run Flare on a network location, but according to this thread, it seems that others are. Perhaps you should try mapping a drive letter to the server to see if your build works.

I haven't tried checking out multiple files from SharePoint, and don't imagine it would be a good user experience. I think some of us jumped to the conclusion that you were trying to use SharePoint as inexpensive source control as well.

Bob

[RamonS]

I second Bob, at least map the UNC path to a drive letter. Using UNC paths gives a 50:50 chance of failure under Windows, although it should work just fine. Also, if you do not use MOSS you basically don't gain anything from SharePoint in regards to sharing files compared to a plain simple file share on the network. And Kevin already mentioned it, pull the files local when you want to work with them, gives much less headaches.

[tomjohnson1492]

Thanks for your responses. I tried mapping drives for the output folder as well, but I still get the same error message. It surprises me that, given that Flare is not a new product and that SharePoint is so common in corporate settings, there isn't more information on this. Oh well.

[Madcap Guru]

Sharepoint has not been tested with Flare, and it uses a strange Source Cotnrol that Flare doesn't alwatys like, IF you generate your files to a local location does it work? and then move them them to Storange point, You can always keep your working files in Storanepoint

[wclass]

For reference, I just tried storing and compiling Flare source on Share Point and the webhelp was generated OK.

The document library I put it in is NOT under SharePoint version control, so no check-in/check-out, and I generated to the default Output folder, which it had to create within the same library. I'm not sure that you can check-out sub-folders all in one go on Share Point (might depend on the version). The compile took 6 minutes - it takes less than a minute when generated on a local drive.

This is not our normal workflow, though. Our files are stored in TFS and we check out to a local drive. Some of our webhelp gets published on Share Point - we can set up destinations for this.