Example Project - Assembly Definition Files

I've tried this feature and it's not working as expected.

I am using macOS Sierra 10.12.6 on a MacBook Pro 15 i7. The project that I'm working on has many plugins and currently is taken about 10 seconds on my computer to recompile. I thought that using Assembly Def Files could reduce that time in a couple of seconds at least.

I followed the instructions and I've added the asmdef files to each directory of each plugin (starting from the most complexes) but the compilations times are exactly the same 10 seconds.

 

does that mean asmdef sync work now?

 

Having problems with asset store plugin that I'm moving to respective asmdef folders, it seems that a private class that contains a public static variable is inaccessible by another assembly.
so in an assembly A
this variable

Code (CSharp):

1.     class SomePrivateClass
2.     {
3.         public static readonly string something = "something";
4.     }

won't be accessible by a class in B

Code (CSharp):

1. SomePrivateClass.something

why is that?

 

Public variables of private classes are only valid in the context they are in to begin with. I thought a private class had to be defined within a public or internal class to even be a thing, and then is limited to the scope of that class. Apparently not, though, based on your statement above -- if it was working before, then my guess is that it was scoping to either the assembly or the namespace. My guess would be the assembly, so that it basically would mean that a private class that isn't nested is the same as declaring an internal class; but I don't know for sure, that's just a guess.

At any rate, if you mark something private or internal in one assembly, then by design in .NET it is not accessible outside that assembly. That's literally what it means. This has not relation to asmdef files in and of themselves, it's simply that they created separate assemblies that are working like .NET assemblies do.

Hope that helps and doesn't come across as hostile in any way; I was trying to be thorough, but may have beat the horse to death.

 

"static" is so weird, it should be banished

 

It's fantastic, it's just "not a class INSTANCE thing." If I have cats in my house, and my house is publicly accessible (through properties and methods like doors and windows), and my cats are private (only accessible when in my house), then both the concept of the cat in my house, and the individual cats, can have variables on them. An instance variable would be the cat's name or weight. A static variable would be the location of the litter box, which is shared for all the cats.

In this case, the public static litterbox is still private if you can't get in my house, since all the cat stuff is private in my house. But if you're in my house, then despite the fact that cats are private (scoped to the house), the litterbox (and any other public properties of the cats) are accessible to anyone in the house.

Strange example, but my cat was meowing at me and it's what popped to mind. Static variables are awesome, particularly when you get into the singleton pattern and so forth, but they can be unintuitive depending on how you learned OOP. Different languages treat some of those conceptual bits kind of differently.

 

Thanks for the bug report, we will look into it.

The .asmdef feature is final for 2017.3 and any changes in coming versions will be backwards compatible with the current system. Currently there are no major changes planned.

 

Check your Editor.log for messages on how long individual assemblies took to compile and how many assemblies are recompiled on changes due to dependencies.

Recompile times might be dominated by domain reload after recompiling. See my previous post in this thread on how to profile domain reload times. https://forum.unity.com/threads/example-project-assembly-definition-files.482313/page-3#post-3292894

 

You're a continual font of really useful information.

I've put something on answers.unity3d.com and answered it myself just to surface your information to more people hopefully (since that was what you suggested on another topic here): https://answers.unity.com/questions/1440012/how-do-you-find-out-what-scripts-are-making-your-c.html

 

I'm not actively using asmdef system yet, so sorry, I have no idea .

 

It seems to, for me, although I'm still on the final beta preview of VS 2017 15.5. Generally speaking it doesn't do the whole-hog insane reloads it used to, although sometimes it does.

 

Summoning @jbevain to provide some insight into the issue with Visual Studio reloading the whole .sln/ all .csproj's.

 

The times when it seems to do it most are when:

* There were no non-asmdef projects.
* But then I install an asset and so of course there's temporarily a non-asmdef project (not that I switch to VS in that time, but it does it in the background since I already had VS open)
* And then I move those non-asmdef scripts into one or more existing asmdef project folders, splitting up the editor and non-editor bits.

In general it usually seems related to moving one file between folders inside unity, if those folders are controlled by different asmdef files. But I wouldn't swear to it, it might just be random. I'll try to keep a closer eye on it from now on.

 

Well the new feature to seamlessly reload the csproj utterly breaks Resharper code generation feature, as it high jacks new file event, so for me it's on constant disable now - thankfully you can disable it.

 

Jetbrains is pretty on point with fixing Unity-related bugs, so if you report that as a bug, it'll probably be fixed in the next Resharper version.

 

Sure, will report this, however it's not Unity-related but caused by VSTU.

The project reload feature is kind of heavy handed here, I would imagine it affect any number of other VS extensions which try to do some post processing on new file.

 

What is the idea behind this fix from RC2 release notes:

"Editor: Fix issue with non-source files being added to all generated .csproj files. Now only added to the .csproj files they belong to."

I regenerated the project files, and non-source files - shaders, *.txt etc, all still all added to the csproj file, regardless where they are in the Assets folder, and duplicated across all the assemblies. This creates a lot of clutter in the solution view.

I'm running RC2 and VS 15.5.

 

Good catch. Same here, I forgot to verify if that was working or not. It's not.

 

This is a mistake in the release notes. This only applies to our .csproj generator that is used for MonoDevelop/Xamarin Studio/VS Code/JetBrains Rider. Visual Studio/VSTU has it's own solution generator which is unaffected by this change.

I've let the VSTU team know that this change has been made in Unity and they will look into applying the same for the VS solution generator.

 

Ah, that makes sense. Thanks!

 

My initial though when I read this release note was "I was under impression VSTU generates csproj files, hmmm...". Turns out I was not wrong after all .

I would be nice if VSTU team could implement the same steps as you did. Thanks for explanations!

 

wanted to add I was on here a few days back bemoaning how hard it was to setup : bloody well worth it though - changed my life - THANKS GUYS. Gone from 1.5 minutes compile time, per change to 9 seconds.. I had no idea how burned out I was holding all my code/debugging in my head for 1.5 minutes per cycle. Whoever proposed this feature at Unity and implemented it : me and my family owe you copious amounts of beer.. T h a n k s!!

 

Yep - it is berry nice.
And what's the problem with asset store plugins? I'm using cinemachine, ASE, panda BT and nested prefabs, all I had to do is drop an asmdef in those folders, one reference to panda and that worked.

 

I initially came up with this idea
https://feedback.unity3d.com/suggestions/only-compile-the-script-you-modify

 

Got you beat by about 6 years. We said something to them about that when we were bemoaning the GC in 2010 and 2011.

 

Many asset store plugins are modular, and have several Editor folders (one for each module).
There's no way to have a amsdef file that encompasses all those Editor folders that have different parents.
An idea was proposed by @x4000 here, that would help with this use-case: having "partial" asmdef files, similar to how partial classes work.

 

Ok, you can take the beer. I hate alcohol.

 

I'm not a fan of alcohol, either. Whoever beat me to it can have the beer, because I bet this was suggested well before I did.

 

Hello Unity friends, we made a VSTU preview build with a fix to our auto-reload feature. This should solve issues noticed by @rastlin with Resharper templates.

If you want to have a look:
https://www.dropbox.com/s/g4zc7tw1s6gof87/vstu2017-3.6.0.99.zip

You should only need to install the vsix file (the extension part running inside Visual Studio 2017). This vsix will replace your current extension with an 'experimental' one, that you can uninstall to go back to the stable version shipped with VS.

Regards
Sebastien Lebreton [MSFT]

 

@sailro: Thanks for that! That seems to work well so far, not that I am using Resharper. I'll keep an eye out and see if that solves the intermittent "still going to do a full reload anyhow" issue that was remaining; odds are they were related.

One question, though -- regarding the C# projects having references to all .txt and .shader and similar files in any folder, regardless if their parent folder is in the asmdef folder tree of the assembly... any plans on a hotfix for that?

 

Hello Sebastien,

Thanks for that, I can confirm the issue seems to be resolved on my end, the Resharper templates are working fine now.

 

Yes this is something we already discussed with @lukaszunity, we should add support for that shortly.
Regards
Sebastien Lebreton [MSFT]

 

Cheers, thanks!