Hmm, even if that works, it circumvents the reason the version has a matching component.
The idea behind xsn to form item version matching is this:
I publish a solution, it is version 1 (512). This solution has a field that is an input for a transaction web service called Input A.
I start 10 of these version 1 forms.
I alter the solution and publish a new version, it is version 2 (1024). This solution moves the input field to Input B and delete Input A.
If versioning is turned off all 10 of the version 1 forms will cease to work. This is because the .xsn file has a reference to Input B and no knowledge of Input A. Trying to open the form or run the web service will cause an error.
With versioning on, whenever I open one of the version 1 forms, it pulls the version 1 of the .xsn which contains the Input A field and the forms work. Meanwhile, any new forms use version 2 and happily use Input B.
In our environments we ensure the /Forms and /Composer Solutions libraries have no limit to versions.
** Scott, meant to post this here, you can delete the direct reply.
------------------------------
Joshua Whitener | Technical Advisor
Exxon Mobil Corporation | 8326258441
------------------------------
Original Message:
Sent: 06-05-2020 08:40
From: Scott Gorski
Subject: Winshuttle Composer Version Problem
We have switched every /FORMS library, on each of our form sites, versioning setting to "No Versioning". Do you see an issue with that Josh? Versus Major enabled and no limit?
The default is set this way for us using SharePoint 2016 when a form site is created, so it is a manual process to correct.
------------------------------
Scott Gorski
General Mills | Data Analyst
Original Message:
Sent: 06-05-2020 07:58
From: Joshua Whitener
Subject: Winshuttle Composer Version Problem
On your forms site there is a /Forms library. This library contains .xsn files that the forms use when loading. Major versioning should be enabled with no limit to the versions kept. Most often what happens with this error is that there is a limit on the major versions and the form is now trying to reference a version of the .xsn file that no longer exists.
You can confirm by checking the SVVersion property on the form item. It will be a multiple of 512 (version 8 of the .xsn would mean SVVersion = 4096).
If this is the case, you may not be able to recover the .xsn file versions needed without a SharePoint recovery. Your next best option is to go to the forms that are having issues and manually update their SVVersion property to pull the oldest .xsn version available.
Just be sure to ensure the /Forms library doesn't have a limit on versions.
------------------------------
Joshua Whitener | Technical Advisor
Exxon Mobil Corporation | 8326258441
Original Message:
Sent: 06-04-2020 16:12
From: Nkosinathi Sithole
Subject: Winshuttle Composer Version Problem
Hi Team.
Please assist. we have a solution in winshuttle composer that has been working perfectly for the past five months. a few modifications were made on the solution and it caused a lot of errors. a backup of the solution file that was properly function was loaded. however, when we try to open previously created forms, we get the following error:
------------------------------
Nkosinathi Sithole | Master Data Officer
THE ROYAL SWAZILAND SUGAR CORPORATION | +26878253987
------------------------------