We’ve just upgraded from 2017.3 to 2018.1 Beta.
We are running into next problem now.
In VS Tools for Unity (3.4 on VS2015) the Unity projects do not want to build anymore:
Error CS1703 Multiple assemblies with equivalent identity have been imported: ‘C:\Program Files\Unity\Editor\Data\MonoBleedingEdge\lib\mono\4.7.1-api\Facades\System.Xml.XmlSerializer.dll’ and ‘C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.6\Facades\System.Xml.XmlSerializer.dll’. Remove one of the duplicate references. UnityEditor.StandardEvents
and the same error for many more of these System.xxx.dll assemblies.
The Unity projects target .NET framework 4.6, just like the other self-made business assemblies that we put under the Plugins folder.
In the Unity.csproj files, I notice that some references are indeed duplicated:
<HintPath>C:\Program Files\Unity\Editor\Data\MonoBleedingEdge\lib\mono\4.6-api\mscorlib.dll</HintPath>
</Reference>
...
<Reference Include="mscorlib">
<HintPath>C:\Program Files\Unity\Editor\Data\MonoBleedingEdge\lib\mono\4.7.1-api\mscorlib.dll</HintPath>
</Reference>```
However, there are more build errors listed than duplicates found in the .csproj
Removing the duplicate references does not help, and next time when re-opening the Unity projects the duplicate references are back again.
Anyone an idea what is going on?
Thanks a lot.
You should probably edit your post to just the case number and remove the link. If you post a link to the fogbugz page, someone can see ALL of your bug reports, which could contain project data that could conceivably be under NDA (like console stuff).
I have “student” solution for that.
Go to inside ‘C:\Program Files\Unity\Editor\Data\MonoBleedingEdge\lib\mono\4.7.1-api\Facades*’ then create BackUp Folder and put(not copy) all .*dll into this folder. Then delete all .*sln solutions and open Project in Unity. Build Succeeded
This should be fixed shortly in Unity. In fact this is related to the way Unity is compiling projects targeting .NET Standard.
As a workaround, you can add the following script in an Editor folder, to patch the project generation:
using System.IO;
using System.Linq;
using System.Text;
using System.Xml.Linq;
using UnityEditor;
#if ENABLE_VSTU
using SyntaxTree.VisualStudio.Unity.Bridge;
[InitializeOnLoad]
public class ProjectFileHook
{
// necessary for XLinq to save the xml project file in utf8
class Utf8StringWriter : StringWriter
{
public override Encoding Encoding
{
get { return Encoding.UTF8; }
}
}
static ProjectFileHook()
{
ProjectFilesGenerator.ProjectFileGeneration += (string name, string content) =>
{
// parse the document and make some changes
var document = XDocument.Parse(content);
var ns = document.Root.Name.Namespace;
document.Root
.Descendants()
.First(x => x.Name.LocalName == "PropertyGroup")
.Add(new XElement(ns + "ImplicitlyExpandNETStandardFacades", "false"),
new XElement(ns + "ImplicitlyExpandDesignTimeFacades", "false"));
// save the changes using the Utf8StringWriter
var str = new Utf8StringWriter();
document.Save(str);
return str.ToString();
};
}
}
#endif
Came up in 2018.3 for me. For some reason I had a few System .dll files in my base Assets directory. I must have put them there in the past to fix a bug I’ve since forgotten about. It appears these .dll files now come with the base engine package. Removing them from my project / asset directory fixed the problem for me and didn’t seem to cause any erroneous after effects.
Specifically they were:
System.Configuration.dll
System.Data.dll
System.EnterpriseServices.dll
System.Security.dll
Encountering this issue in 2018.4 still. @sailro 's suggested workdaround did not work for me because I generate builds external from Unity3D and auto-import the generated assemblies. This is preventing me from using .NET Standard 2.0 Azure Service Bus library from within Unity3D.