Potential issue with build target retention on BuildAssetBundleExplicitAssetName

There seems to be some issue with 3.x versions of the Unity BuildAssetBundles functionality. It does not happen all the time but it happens a lot. We build several asset bundles which we have written a simple Editor tool to do. After implementing the tool to export the bundles we noticed that after running the tool (OSX and Windows) we would randomly get errors that indicated the core mono libraries no longer supported very common calls to certain collections and System.IO classes. A previously long running thread about this can be seen here. The bundles work great though and there are no errors cause by the bundling process.

To eliminate this problem it is necessary to go into the build settings and *reset* the build settings to Standalone mac and PC where it had been moved to Web Player. I have realized recently that the default build target for building the asset bundles is the web player unless you tell it otherwise. This is no huge revelation, but I think that building asset bundles must do a swap-a-roo on the core target libraries to take advantage of target specific media and image libraries to build the bundles but it does not swap the target back for continued editor or command line use.

If you are building bundles for stand alone OSX and PC and fail to set the build target to the platform you are on, then the default build target (Web Player) will be set and your core libraries will have changed creating the strange compile errors like this:

error CS0117: `System.IO.File' does not contain a definition for `WriteAllText'

Does this mean that you essentially can only build bundles for the target you are on? That is unless you want to reset the target every so often before you build but that this is not an option on an automated build system. Trying to run Unity or invoke it from the command line after the bundles are built for a target other than the host it fails with

Code (csharp):

1. Aborting batch mode due to failure:
2. Scripts have compiler errors.
3. ***Thread was not cleaned up!***

I think the workaround for this may be to conditionally set the build target to the host target so it gets reset to what it is supposed to be. For Mac vs PC standalone I don't think this will be an issue.

Edit: 2/4/11
This seems to work around the problem. Basically I set the asset bundle script to set the target platform for the bundles to a platform that is compatible with the editor type (like WindowsEditor would target WindowsStandalone, MacEditor would be OSX universal, etc.) Luckily, this works for me because I don't think there is any difference between Intel OSX and PC bundles. It's much faster too. It seems that doing this eliminates the need for Unity to traverse the project looking for assets to port to the newly switched target because the target libraries have been switched. I am going to enter a bug with Unity for this.