[Workaround] Upgrade from Unity 2017 to 2018 produces empty .transfer files

[dgoyette]

Short version: The process to upgrade my 2017.4 project to Unity 2018.1 is generating almost entirely empty ".transfer" files for my substances.

I'm trying to upgrade my project from Unity 2017.4 to Unity 2018.1, and I'm following the process described here:

https://support.allegorithmic.com/documentation/display/integrations/Upgrading+2017.x+projects

I'm performing the steps within the Unity 2017.4 project, which I will be later opening in Unity 2018. After the upgrade completes, I see that it has created one ".transfer" file for each of my SBSAR files. However, of the 50+ SBSAR files I have, all but one of those ".transfer" files is completely empty. The files have no content. There is a single ".transfer" file that has some content, but the XML in the file is incomplete. The file is 86 lines long, and it ends in the following:

      <FileID>237430997</FileID>
      <GUID>9fa6918a1f28f90409761cec68c7f525</GUID>
      <TargetSetting>
        <BuildTarget>Default</BuildTarget>
        <TextureWidth>2048</TextureWidth>
        <TextureHeight>2048</TextureHeight>
        <TextureFormat>0</Textu

Note that the closing <Texture> tag is cut off in the file.

It's difficult to pin down whether any meaningful errors are occurring during this process, because my console log is full of thousands of cases of the following (which started after installing the Substance Updater package):

FileNotFoundException: Could not load file or assembly 'Substance.Game, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
UnityEditor.EditorApplication.Internal_CallUpdateFunctions () (at C:/buildslave/unity/build/Editor/Mono/EditorApplication.cs:127)

However, I do see these two errors as well:

Assertion failed: Assertion failed on expression: 'exception != SCRIPTING_NULL'
Couldn't extract exception string from exception (another exception of class 'ArgumentException' was thrown while processing the stack trace)

Those are appearing often.

So, is there some known reason why the ".transfer" files would be empty? Or why one of them wasn't empty, but was incomplete?

Possibly related, the moment I confirm that I want to do the update, I immediately see the dialog that states "All substances have been updated successfully." However, at that point nothing is done, and Unity will churn for a minute or two before the files are generated.

[dgoyette]

The issue of empty .transfer files appears to be caused by `XML.Encode(asset, reflectionPath);`  The asset has data in it, but the Encode call is returning an empty string:

[dgoyette]

I've been continuing to work on this issue, to hopefully determine a specific cause, and it appears that this happens when the .NET Version (Edit -> Project Settings -> Player -> Other Settings -> Scripting Runtime Version) is set to 4.6 instead of 3.5.

I create a test project that contained only one SBSAR, installed the SubstanceUpdater asset, and found that it correctly generated the .transfer file. I repeated the process, this time changing the .NET version to 4.6 (which is the version I'm using in my real project) and found that the resulting .transfer file was empty. Switching back to .NET 3.5 results in correct generation of the files.

I don't see anything on the upgrade instructions that indicates the .NET version is a consideration, so maybe this isn't happening to everyone. But for me this appears to be the issue. Downgrading a project to 3.5 is a hassle, but it's possible a workaround for anyone else in this situation.

Any chance for an official response on this though?

[Wes McDermott]

I've been continuing to work on this issue, to hopefully determine a specific cause, and it appears that this happens when the .NET Version (Edit -> Project Settings -> Player -> Other Settings -> Scripting Runtime Version) is set to 4.6 instead of 3.5.

I create a test project that contained only one SBSAR, installed the SubstanceUpdater asset, and found that it correctly generated the .transfer file. I repeated the process, this time changing the .NET version to 4.6 (which is the version I'm using in my real project) and found that the resulting .transfer file was empty. Switching back to .NET 3.5 results in correct generation of the files.

I don't see anything on the upgrade instructions that indicates the .NET version is a consideration, so maybe this isn't happening to everyone. But for me this appears to be the issue. Downgrading a project to 3.5 is a hassle, but it's possible a workaround for anyone else in this situation.

Any chance for an official response on this though?

Hi,

Thanks for posting this information. I've asked the devs to take a look and reply to this thread.

Cheers,
Wes