I had Assembly Definition Files working fine in my project, until I switched to a different machine (both running Windows 10). Now whenever I add one it doesn’t create the additional .csproj file and opening Visual Studio will yield one or several errors (one for every assembly) saying that ‘the project [unity project name] cannot be added to the solution because a project with the same project filename already exists in the solution’.
Unity does appear to compile them just fine, but with about 10 errors popping up every time I open VS and no Intellisense support it’s not workable.
I had the same problem and solved it by updating to the latest version of Visual Studio Tools for Unity. It does actually say in the release notes for version 2017.3 that you need the latest version for assembly definition files to work with VS, but I admit I missed that originally.
If like me you’re using Visual Studio 2017 Community, the Tools for Unity appear to be built in to VS, so upgrading VS 2017 also upgrades the tools. For me, doing so updated version 3.3.0.2 of the tools to 3.5.0.2. Assembly definition files now work perfectly, with each separate assembly being created as a separate project within the solution.
I’m on Visual Studio Community 2017 and have Unity VS Tools v3.5.0.2 installed and I cleaned the project (deleted: Library / *.vs / *.csproj / *.sln) - yet this “project cannot be added to the solution” error persists. Is there anything else I could try?
Also, on Visual Studio 2015 the VS Tools are still on v3.4.0.2, these ought to be updated really if they are required for Assembly Definition Files to work. Otherwise VS2015 users are locked out from using assembly definition files. I couldn’t find any other download than the VS Marketplace here: Visual Studio 2015 Tools for Unity - Visual Studio Marketplace
Strangely though the asmdef worked fine until I had a compilation error that wouldn’t go away (missing references due to adding assembly defs) and in the process of fixing those I noticed VS got confused and pointed out errors that couldn’t possibly happen (namespace doesn’t exist) so I decided to wipe the csproj, sln and Library at which point I started getting the aforementioned error. Before that, everything seemed to be alright.
Luckily I found this out BEFORE submitting my asmdef changes to the whole team …
Also: if you put your Unit Test (Testrunner) files in an Assembly Definition those tests won’t appear in the TestRunner window. Just thought I’d mention this.
I was too quick about it. As soon as I add an Assembly Def in a subfolder of an existing one I keep getting the same error.
A bit more info on my Problem. Project with 3 folders under /Assets:
Examples
Plugins
Tests
When I create an asmdef under /Assets the TestRunner tests (under Test folder) disappear, so I cannot do that. When I create an asmdef under Plugins everything is fine. I create a second one under Examples and make it reference the Plugins asmdef. All fine.
But as soon as I add an asmdef under Plugins/Subfolder I get the “project cannot be loaded” error in VS 2017 even with VSTU 3.6
Update:
I started over from scratch, creating assembly definition files and every time closing VS, removing csproj and sln from project and re-opening VS. This got rid of the problem that the additional csproj were not generated. However building in VS initially caused two errors (missing metafiles for DLLs) and subsequently it emits warnings (access to some xml files was denied). It kind of seems to work now but it still feels very brittle. I’ll keep investigating.
Some “odd” things I noticed:
renaming an asmdef will not rename its “Name” field ie the name of the DLL/project - for me it feels they ought to be the same but there may be a reason to have them separate
changing the “Name” field of an asmdef will break all existing references to that asmdef (unexpected, feels broken)
Ok, I think I’m on to something. For me it breaks whenever I set the asmdef Name field to have a “Assembly-” prefix, for instance “Assembly-Examples”.
Now that I removed the “Assembly-” prefix from all three asmdef and updated the references, then deleting csproj & sln and also restarting Unity and VS (just to be sure) everything is back on track and I have no problems anymore.
Yes, I already noticed that “Assembly-CSharp” is a reserved name and Unity complains if you try to set an asmdef Name to that - that made me think how these kind of “let’s check a string for some pattern” checks often end up being implemented incorrectly or inconsistently, therefore I decided to also remove my “Assembly-” prefix from the asmdef.
