MadCap Software Forums

I changed folder names in a Flare project that updated links in targets. This caused the error in the attached file.

<Exception type="System.InvalidOperationException" message="Sequence contains more than one element"

(full error log in attached file).

What is the issue/problem?

Just happened to me too - did you ever find a solution?

I have also experienced this a number of times and have reported it. I haven't been told about a solution yet.

We're getting it now, too. Does anyone moderate these forums anymore? Seems like answers are few and far between on most topics I've searched lately.

We got the error while trying to push updated info from Flare to GitLab.

Flare Support told me that they thought it was a connection issue... They suggested I create a new repository on Git and bind my project (or a test project) to that. I did this a few weeks ago, and so far so good, but I wouldn't be surprised if I start seeing this issue again.

I just started getting this error too. I had recently changed several filenames (not folder names, as the OP did). Maybe that has something to do with it.

Based on the advice from Flare that kerimucci received, I just tried unbinding and rebinding my Bitbucket repo, and I'm not getting the error any more. Interesting.

I just discovered that unbinding the repository apparently emptied it! That was a negative side effect I definitely wasn't expecting. Afterward, even when I committed my project from Flare, it didn't show up in the repo. I had to unbind, delete the repo, recreate it, and bind again to get things working properly.

It seems like this is a pretty significant bug that needs high priority attention from MadCap.

kathryngz wrote:It seems like this is a pretty significant bug that needs high priority attention from MadCap.

Be sure to report it at https://www.madcapsoftware.com/feedback/bugs/. MadCap does not necessarily monitor what's being reported here in the peer-to-peer forums.

Nita Beck wrote:

kathryngz wrote:It seems like this is a pretty significant bug that needs high priority attention from MadCap.

Be sure to report it at https://www.madcapsoftware.com/feedback/bugs/. MadCap does not necessarily monitor what's being reported here in the peer-to-peer forums.

I just logged this bug this morning with a similar issue we're having, along with Support case under our Bronze maintenance package. Will report the findings here when we (hopefully) have a solution).

Any of you continuing to experience this error after unbinding and rebinding? I am getting the same error and just curious if this is a temporary workaround or if this issue keeps coming back? Planning to unbind and rebind and hope it resolves it.

@wolfmanjack - I don’t know if it depends on your source control tool, but we cannot “rebind” a project. We use GitLab.After we unbound the project, we had to blow away our local copy, and then do a fresh Import of the project. This error occurred on only one person’s copy, so not a big deal. But, it did recur a couple of times. As I recall, he ended up uninstalling and reinstalling Flare. We haven’t had the error since then... thus far.

neb123 wrote:I changed folder names in a Flare project that updated links in targets. This caused the error in the attached file.

<Exception type="System.InvalidOperationException" message="Sequence contains more than one element"

(full error log in attached file).

What is the issue/problem?

I am having a similar issue. I made some change to the folder names and Flare has been crashing ever since. The moment I select the project to open, I get a message from Flare. I haven't been able to open the project. We use Github as our repository. Is there any other way to unbind the project from the source control, as I am currently unable to even open the project to unbind it. Flare crashes even before that.

I've started getting this error repeatedly. My Flare project is bound to Central. I'm told it might be Git related, so curious how many of you who get this error are using Git.

Here is the "fix" from MadCap, which is not really a fix but more of a "unplug it and plug it back in" solution until it happens again. It is recurring for me. My project is still pretty new and small, and there's nothing remarkable about it. I'm not doing anything complicated in the content, and the error happens at random times, like when I try to apply a text style, or insert a snippet, or various other mundane tasks. These are the steps they have me follow when I get the error:

1 Open the project folder in Windows File Explorer and delete the .git file
2 Open the flprj using text editor
3 Delete all Source Control-related text here
4 Save the file
5 Open the flprj inside Flare again
6 Open left-pane MadCap Central tab
7 Click "Upload this project to MadCap Central"
8 Rename the project so that it has a new repository created within Central

How about that. I just started getting this message today, only I'm bound to GitHub, which is what we use, not Central, which we saw no reason to pay extra for.

Seems to have started happening after I changed a couple of filenames. (I wonder if it's also an issue with 2FA, which Flare (still!) doesn't support.)

Is anyone more familiar with how Git/GitHub works (which would be pretty much anyone) and could adapt these instructions safely to GitHub?

I have just renamed/moved some files and directories and I have the same issue now.
I'm using Git at Bitbucket.
Tried unbinding/binding - did not help.

So, these are my findings:
When I moved/renamed files and folders in Flare, it looks like it did something strange to the Git index.
I have reset my local repository to the previous commit (hard reset using TortoiseGit), and then ran the command:
git gc --prune=now

Now Flare can pull and push changes again.

I've seen this error quite a few times now. Up until today my method of recovery was to rename the local project folder, clone the remote from the last commit+push, and then compare files to recreate the changes I'd made locally since the last commit+push. This gets old fast.

I tried something else today, and it was much easier. Perhaps it will help you too:

(Note that I use BitBucket for my remote Git repository, and I use SourceTree for operations that aren't native to Flare - I'm don't know how well this method will work for other combinations.)

The 'Sequence' error popped up again in Flare, and I could no longer commit and push changes to the remote repository, as described by other users in this thread. Recovery as follows:

1. I switched to SourceTree instead and used this to stage/commit/push all the files I'd changed in the local project folder. This worked without any trouble.
2. I renamed the local project folder, just in case I need to fall back on a diff/compare method.
3. I cloned the remote repo back to local under the original project folder name.

Now it works as it should again - I don't see the error anymore and all seems to be fine, so I'll delete the renamed folder shortly. I hope this helps.

Well, I gave up. I pretty much did what TechOnTheBrain did.

But first, let me just say that MadCap has NEVER gotten integrated source control working correctly or (nearly) bug free. I had the same type of frustrating issues using Flare for a different company nearly a decade ago. It's pretty damn shameful that they haven't gotten this right, with both intellectual property and security being so important to any company that develops any product. And anyone who wants be an apologiist for MadCap's utter failure in this area can go take a long walk off a short pier.

I started by unbinding my project.
I backed up the entire project in two different places.
I renamed the repo in GitHub to closely match the folder I used locally.
In GitHub Desktop, I cloned that repo to its local parent's folder. I now had two similarly named folders locally.
In the cloned repo, I deleted all the files, then copied all the filed from the backup into the repo folder.
In GitHub Desktop, I saw LOTS of changes. I selected all, committed to master, then pushed to origin. Everything that was up-to-date was now in GitHub as I wanted it.

I did a few tests. I added a topic file, added a bit of content, then went through the commit/push process a few times. In the testing, I had to add a few things to the .gitignore file, such as the Output/Temporary/ folder and a few other temporary/status files that Flare creates as part of its project management. I'll probably add a few more as time goes on, building what I hope to be a fairly comprehensive and useful .gitignore file. From here on out, I'm using GitHub Desktop, not Flare, for my source control management.

I will not allow any Flare project to bind to any source control ever again. I'll do all of the source control functionality outside of Flare and recommend to anyone who will listen to do the same. It's just not worth the headaches of dealing with buggy, unreliable code. I cannot trust Flare to do this consistently correctly.

I had his issue, too. [Flare 2018r2; project bound to bitbucket] My solution:

1. File > Import Project > From Source Control
2. Go thru the dialogs as directed, but I imported to a new directory (same name as the original dir, but appended "A_" to the name)

I pulled down all the project files and can work away in the new dir. I might, eventually, delete the original dir, but for now I am leaving it.

This is a horrible bug. Must fix. I did the same workaround before, but it does not give me confidence in the source control capability. Also, how will the whole team feel being harassed by such errors? This error completely prevents us from even undoing the offending change. The error just hijacks my system and offers no insight about what the "duplicate" file might be. Did I make a mistake convincing my company to get Central? We have barely deployed and already this has happened twice. Not great for building confidence.

I have a hunch as to why these errors occur. It's my experience that if I have been editing files and then, while they are still in a checked out state, I rename or move those files -- or I rename or move the folder those files are in -- I will get these errors. I've seen this not only with Flare's Git integration but also its SVN integration. Can't speak to other source control options.

My advice to my clients (one of whom got these errors just yesterday) and here to my Flare friends is this:

Check in edits and renames/moves as SEPARATE operations.

If you've been editing files and then need to rename/move them, FIRST check in the edits. Then go about the rename/move and then check in that change before doing anything else.

If you've just renamed/moved some files and now want to edit them, FIRST check in the renames/moves, yada yada yada.

I can argue that Flare shouldn't be this finicky. But it is, and this best practice has tended to keep my clients and me from getting these errors.

I've hit this issue - we're using Madcap Flare 2019 with Git/Azure - and yes, it happened just after I renamed some files and then edited one. Flare seems to really hate this.

P.

This is ringing some bells from way back.

I seem to remember years ago that when you do a rename in Flare, behind the scenes Flare actually deletes the old file from source control and adds a new file with the new name and it gets a "Pending Add" status rather than "Checked Out" status.

So maybe this is the sequence?
1. Edit file. Source control status is "Checked out".
2. Rename file. Old file deleted and new file added with source control status "pending add".
3. Check in. Fail because you can't "check in" a "pending add" file? I feel that in source control there was a different option, not Check In, for Pending Add files.

This is all from memory, mind, and I don't have access to source control at the moment to check terminology (we were using TFS at the time). But maybe my fuzzy recollections can help someone figure out what's going on.

oceanclub wrote:I've hit this issue - we're using Madcap Flare 2019 with Git/Azure - and yes, it happened just after I renamed some files and then edited one. Flare seems to really hate this.

P.

This is why I do not bind to source control in Flare. I've never not had issues with Flare bound to source control, from Perforce way back when to Git/Github today. I simply use GitHub Desktop to push changes to my repo and never have to worry about Flare managing anything. I would recommend this any day of the week and twice on Sunday.

Psider wrote: I seem to remember years ago that when you do a rename in Flare, behind the scenes Flare actually deletes the old file from source control and adds a new file with the new name and it gets a "Pending Add" status rather than "Checked Out" status.

This is not, I think, a "Flare" thing, but a source control thing. I do not have my source files repo bound in Flare. But when I rename a file, in GitHub Desktop, I see that the original file was deleted and a new file was added to the repo. I think that's how source control systems, or at least Git, "handles" renamed files (which, BTW, I think is not optimal; I'm guessing this "breaks" the change tracking of a file).