Unity Future .NET Development Status

SourceGenerators really are not hard to get working in unity 2022+ now, give it a shot. Just make sure to use the compatible CodeAnalysis.CSharp package, and not the latest one.

Since SourceGenerators in standard .net are usually referenced from the csproj or a Nuget package, the transition to csproj will definitely make working with them easier.

 

If it's your own assembly:
- [InternalsVisibleTo()]

If it's not your assembly:
- in the spirit of Dotnet: Ask the author to make commonly useful / needed things public

---Use sparingly------
- if it's a Unity package, name your assembly like the Unity debug / test assembly

-----very much last resort-----
- [IgnoreAccessChecksTo()]

-------unsafe--------
- inject [InternalsVisibleTo()] into the assembly

 

None of those things achieve anything remotely similar to asmref? asmref is just "put these files into this assembly in some other folder"

That's a sensible thing to keep around as a feature! There will have to be some automatic updating of csproj files anyway (when you add a new file to a folder, it'll have to be included in the list of files in there), so an asmref that links to a csproj would just be a part of that pipeline.

 

What you're stating is what asmrefs are *supposed to do*. But as you can see:

that is not what they want them for, so I replied to *their issue*.

Nevertheless, for

amsrefs are still not needed, since csproj supports this natively, and has, from the beginning, rendering your point absolutely pointless.

 

How would this translate in terms of usability ?
Right now there's module packages that put their code with

asmrefs

on a "core" package with an

asmdef

, which uses defines based on presence of the module package to enable/disable functionality
would csproj files have that kind of stright forward interop?
with automatic steps like rebuild upon module package import ?

And why would the majority of devs have to spend more time & effort to manually configure this kind of work instead of just using the asmdef/ref UI ?

 

It supports that natively by editing the file. Usually the IDE does that. That says nothing about how the users will set that up from within Unity.

I guess you could require people to use an IDE or hand-edit the csproj file, but both of those seem unlikely! A feature being supported is meaningless if you can't use it.

The question of "how do you decide which files goes into the csproj" has a bunch of potential solutions, and the most appealing one to me is "something like the asmdef/asmref solution", where files and folders that's in the same folder as a csproj file is automatically added to it, and then you can have a special file type that links too the csproj file in order to override that process.

The alternatives are things like:
- having a list in the csproj file's inspector of which extra folders to include
- Removing the feature unless you want to script some thing to manually edit the file
- Disallow users from using Unity without an IDE

All of those are bad and annoying! Unity needs to manually update the csproj files anyway, so having a way to interact with that process would be necessary.

 

Oh, and the ability to use an asmref to go "hey, please consider this folder to be a part of the assembly from a package like

UnityEngine.UI

is super useful! Having to fork all of Unity's packages in order to access grown up mode where you get to edit data would be a big downgrade of the entire engine.

Suggesting that you "Ask the author to make commonly useful / needed things public" is... have you ever tried asking somebody working at Unity that? There's no faster way to get ghosted.

 

Ok now i'm not sure if the heat is just getting to everyone's head, or what.
Why would you want to change where code goes, which can easily break code compilation, without opening any IDE?
1. - that's simply stupid,
2. - that makes no sense

Also i very much expect the csproj to *not* have an inspector, because it lies *outside* of the Assets folder anyway, as it does now, and as it should.

 

Why are you then ignoring all other points except 'Ask the author to make things public'?

There are even more ways to achieve this than I listed before too.

 

yes, csproj also supports defining preprocessors, also conditionally, which is essentially what asmdef does currently

 

Some people like to use other kinds of editors for their code? Unity has always supported editing code in emacs, vim, etc. for the old crudgeons and/or stary-eyed idealists that wants to do that. Going "Pay for Visual Studio/Rider, suffer VS Code being ass or change game engine" would be a pretty large change of course for Unity as an organization. I'm assuming that's not part of the plan.

I just wanted to comment that it wasn't very realistic of an option. The other ones are not helpful, but if you want feedback, sure. If the assumption is that the asmref is added in order to make code that's marked as internal useable by your own code without reflection:

If it's your own assembly:
- [InternalsVisibleTo()]
Not relevant since it's not your own assembly.

---Use sparingly------
- if it's a Unity package, name your assembly like the Unity debug / test assembly
I don't think this does anything? I don't think having assemblies that happen to have magic names will help me - unless there's some hidden feature where an assembly named MyAssembly.Tests has access to MyAssembly's internals? I don't get this point at all.

-----very much last resort-----
- [IgnoreAccessChecksTo()]
I haven't seen this before, but some quick googling seems to imply that it only disables some runtime checks, and that you actually have to do your own compilation in order to bypass compile-time checks? It also allows access to private members, which is not what was asked for either.

-------unsafe--------
- inject [InternalsVisibleTo()] into the assembly
This was what was asked for, but you don't really explain how to do it? Are you suggesting that we do some compile-time shenanigans in order to get the same access as before? And how is this unsafe?

 

Maybe i didn't write clearly, i know csproj supports preprocessor defines, i was talking about their usage coupled with asmdefs + asmrefs to make modular upm packages (that can function with and without a module)

because currently they're used like this, and it's a great resulting feature, which by my knowledge wouldn't be feasible without asmdefs/refs

What about UX, DX, devs who want none of those added manual steps, non-devs, upm packages ?

 

Imo either asmdefs should remain, or a solution maybe based on csprojs would have to be designed and developed, that doesn't downgrade the current workflow & feature set

But that's far-fetched imo

 

I would very much enjoy an inspector where I can quickly add trivial stuff like

#nullable enabled

, reference the

UI module

, use

.NET 8 - preview

. I know how to do it, but it would remove trial-and-error when e.g. mistyping, checking for correct naming etc.

Edit:
I got convinced of the contrary
https://forum.unity.com/threads/unity-future-net-development-status.1092205/page-39#post-9241551

 

Unity packages have various [InternalsVisibleTo()] attributes to test assemblies, so you could use such a test assembly name for a trivial wrapper.

It is very much usable, even without own compilation, if you know how, and accessing privates is not an 'asked for feature' but nevertheless arguably even more useful than just internals.

This wasn't asked for, even explicitly stated not wanting to do that. Unsafe because it's most easily done through reflection or other considered unsafe means.

What about any of those people who use winforms, wpf, blazor, maui, or....? I'd say asmref / asmdef is way more 'manual' than csproj.

Not quite sure what you expect here. If you want to make a modular package, you can define your preprocessor directives in the csproj's and use those in your submodules or whatev, and have a modular package like that.

No i disagree heavily here. That's all stuff that is *exclusively* needed in code, so in code it should stay, which is exactly what csproj is for. If you're working with code, you use an ide, if you have an ide, it supports changing this. Unity does not need and should not interfere with this.
Imagine a UX artist reading a post like '.net 12 now 15% faster' and be like: 'oh great, i read something like that in an asset' then changing your target framework randomly through unity. Horrendous.

 

You're thinking of classic csproj, which Unity currently uses. Modern csproj, which Unity will move to with the .Net upgrade, does not require editing the csproj to include more files. Modern csproj automatically includes all

*.cs

files in the same directory and sub-directories.

 

Yes, also if you want to include some code way outside of the current directory, new csproj, which is the csproj i'm talking about this whole time, does support that.

Also for anyone who said, says, or thinks, of 'writing a lot in csproj', take an actual look at the new csproj, cause i'm certain you are thinking of the old .net framework csproj.

 

This is not possible if you want the same thing as @Mindstyler, see

If you have csproj files outside of the assets folder, then you can't use location of the csproj file to do anything, since they're all in the same place!

Anyways, using an asmref implies that you want code from outside the same directory to be compiled into the same assembly, and it implies that you want to specify that from within Unity.
Which, like, is totally possible! But y'all seem to think that it'll ruin your workflow or whatever.

imo, the cleanest option would be to use csproj files that's embedded inside the project, and then some kind of inspector on them to edit their settings, as well as either a) some kind of other file type that links a folder to a csproj or b) some kind of visualization in the Project View to show that a folder is included in a different csproj file than the default one. Then you could have a toggle to turn off Unity messing with the csproj files in cases where you want to do special things where you manage what's in them through other means than the editor.


To be clear, I'd be happy with a solution where all managing of code happened inside of Rider, but I know that
a) Unity's pushing to be friendly to beginners and non-programmers, so it's probably not going to happen at all anyways!
b) half our programmers would quit if they were forced to sit in a "slow, buggy piece of S*** that gets in the way of their work" (any IDE to them), and I'd rather not have to replace them. Don't know the percentage around other studios, but I've seen Unity's old CTO present on stage with emacs, so it's probably not foreign to Unity that those programmers can be valuable.

 

csprojs and asmdefs could still coexist, or am i wrong?, so those frameworks are not out of the way

That would increase the number of dlls dramatically, like 5-10 dlls instead of 1 for each modular package
and there are popular modular assetstore systems/tools using asmrefs

Obviously i leave the decision to Unity, i m just stating that there are also lots of people with other priorities than those you stated for which asmdef deprecation would be a downgrade, if there's a solution out there that does not boil down to that, then it's welcome

 

This is what i mean by keeping the current asmdef to act as "front-end" to csprojs,
it would theoretically allow to keep asmrefs that would just act as a configuration asset to include its folder in the same csproj,
i mean isn't this similar to what's already being done anyway? there's only the csproj editability & toggle feature to add ?

 

When in doubt, ask @JoshPeterson

Hey @JoshPeterson what about asmrefs?

 

On the contrary, this is still quite possible.

Also, please people, stop arguing for 'non-programmers' when discussing a *purely* programming related topic. And stop arguing for 'beginners' when discussing a topic no beginner would use when starting out, just as no beginner uses asmdef / asmref.

awful programmer mentality, but nevertheless: open a text editor, write 1 line, you're done.

If Unity scribbles together a strange custom way of handling csproj, then they shouldn't bother at all, since it's not helpful, except for Nuget. They did this with .net for years, now everyone's been complaining about it for years. Now they want to get up to par with everything, even support csproj, which has been received incredibly well recently, .....but now come all the people who cry about not wanting to adapt their 'workflow'.

 

An editability feature to allow to bypass asmdefs allowing manual csprojs would be a good fit, why downgrade the experience for others just because someone perceives them as less competent?

We're all excited about the new progress in this area, it doesn't mean Unity has to scrub a feature because the new solution has improved usability, but just to adapt it.. (the toggle)

A problem that concerns most users isn't solved with a vision that accounts for one viewpoint

 

You know what, you actually convinced me. Who knows what the future holds for .csproj? Only editing via script-editor, not having to wait for Unity to keep up when .csproj gets cool new features is probably best.

 

Nope, the existence of an automatic solution is non-negotiable. The moment when someone deletes the original file and replaces it with a new one the whole system breaks. Automatic import ensures no one effs it up.

 

I also strongly support the mentality to keep things as simple and clean as possible. It should not be a problem to edit a simple csproj file to your needs - once you get the hang of it, it's much more powerful than asmdef/asmref.
Also there is pretty good IDE support out of the box.

The argument of not wanting to use any IDE does not count - as then the Unity Editor would serve as your IDE - which is the worse decision as it won't keep up-to-date with all csproj changes that will be coming in the future!

 

So, how do you do what asmref very importantly does?

It's an inverted include, so the target folder says "I want to be included in XYZ project". And it is like this mainly because the UPM packages are read-only (as they should be), but if you want to reach into it, you need an interface where you can inject your code. That is the asmref, it sits in a writeable folder along with your own code, but it acts like it is part of another package.

So how do we get structure of csproj files, we don't get dozens in one folder (one for each UPM package plus your own ones)?

 

Alright, I still have some things to say to that.
1- look at my previous posts where i listed quite a few possibilities, and there are even more that i didn't list.
2- actually, if you look 1.5 years or so back in this thread, i was already kind of asking this question (was just asking what the 1-1 equivalent csproj property was) and Unity officially responded, JoshPeterson iirc, that this asmref 'feature' is really a feature-abuse, and that they have no intention of bringing this over to csproj, which is good.
If you really need it, i've listed some possibilities, and all of those are also very much a lot more expressive in showing anyone who looks at the code that what you are doing is inherently 'unsafe' and can break at any time. And that is another bonus to using plain csproj.

 

None of that helps with circular dependencies or with extension methods when it comes to UPM packages. So no bueno.

 

Wdym it doesn't help with circular dependencies? If you have any circular dependencies you're doing something wrong in the first place. It always was and is good practice to split the circular link into it's own assembly.
And extension methods you can just define in your own code. Those don't need to be part of any different assembly.

 

thank you! This is exactly what I needed. It's not documented anywhere, but there are so many useful lowlevel APIs in Unity that are internal. (The whole

Unity.Baselib.LowLevel.Binding

class to name one)

 

:thumbsup:
If you've got more questions about it, just ask.

 

for future
https://github.com/aelij/IgnoresAccessChecksToGenerator

 

I agree!
1. The source generators have been superseded by incremental source generators, which Unity doesn't support.
2. When I tried to write one, I noticed that one of my packages removed the blue tag button required to flag a DLL as a source generator (That took hours to find )

If they would just work, preferably without creating a custom DLL, that would be incredible!

 

Modern csproj is so powerful, you can do this:

Code (xml):

1. <ItemGroup>
2.     <Compile Include="path/to/my/directory/**/*.cs" />
3. </ItemGroup>

Also, I see no reason why Unity can't start using csproj inside

Assets

folders, like they currently do with asmdefs. (Although it would be better to support showing other folders besides

Assets

and

Packages

in the

Project

window.)

 

I think they will, but that just like script files you have to double-click and open the file to edit it.

Doesn’t .csproj already show up when you put it in the assets folder?

 

It is better to get rid of all the old and switch to the new (or to the appropriate standard, thereby not coming up with your own solutions on top)

 

I'm not sure if it has been mentioned before, but i have a usecase which i think is valid and is not covered by assembly definition files at the moment.

We have a large existing codebase for which we are not interested in separating in assemblies. However, we'd like to introduce tests to these which ideally are in a separate assembly, but refer to the builtin Assembly-CSharp.

This doesnt appear to be possible at the moment, my wacky workarounds end up nowhere. So to clarify, NewAssembly is an assembly that is not Auto Referenced, so not included in Assembly-CSharp. I would like that assembly to access our main codebase, and not the other way around.

 

With Assembly-CSharp-Editor, it looks like what you want to do is achievable, is it?
Assembly-CSharp-Editor references Assembly-CSharp.
https://docs.unity3d.com/2022.2/Documentation/Manual/ScriptCompileOrderFolders.html

 

Hi . Would there still be a .meta file for each .cs file in this future of .Net integration? If not, are there any ideas for how renaming scripts without losing references in the Editor could work?

Also, I have a question that isn't related to the csproj thing. Currently, UnityEngine.Objects don't play well with WeakReferences. The native objects still count those references when deciding if they should be unloaded, which really limits the usability of WeakReferences. This functionality is something I really miss from other frameworks sometimes. With the engine now being more integrated with C#'s garbage handling, could this WeakReference support change?

Thanks!

 

Also storing icons for your scripts without using Icon attribute. Since this attribute is currently rather inconvenient

 

I think the functionality could be improved; e.g. it doesn't work well for ScriptableObjects in the Project View. I believe the main inconvenience for most people is the need to depend on fixed paths as strings. It's a big inconvenience; I've found workarounds by subclassing the attribute and finding the folder that contains my icons dynamically, but it's not pretty.

Maybe an alternative solution could be to define which classes use the Icon in the Icon's .meta file, instead of the other way around? In general, I'm not opposed to using attributes for these things, they can be nice. But the current attributes available for these problems don't do well enough to be the main answer.

Another example is the undocumented MovedFromAttribute which is currently the only way to rename classes used with [SerializeReference] fields. It works well enough when renaming a single class, but it's a pain when renaming a namespace or an assembly, as one needs to add it to every single class inside it, and it's easy to miss one.

I want to add that I'm not meaning this as an argument against separating all the script-related stuff from the rest of the assets in Unity. There are multiple challenges in that, but also many awesome possibilities. If the plan is to remove .cs.meta files, maybe there are improvements to the API that would really benefit that case, and they could also benefit the current .asmdef workflow? Like the way the features for skipping Domain Reload are useful right now, but are almost mandatory for the planned changes.

 

That has nothing to do with the build system afaik...
Meta files are specifically for Unity's filesystem, not the other way around!

Exactly what I just said above.
Thats what meta files are designed for and not building!

Honestly this should be discussed in its own thread, no?

 

I remember there were talks about allowing code to live outside of Assets folder and multiple MonoBehaviours in one file support. Hence the question

 

You don't need to use the attribute: Assign an icon to the script in the inspector and then that icon is used for all ScriptableObject/MonoBehaviour instances of that script. You can use Unity's pre-defined icons or a texture anywhere in your project. This is saved in the script's meta file.

 

So...you have your code assembly. And you want a seperate assembly with tests. That assembly should be able to use the main code assembly, to perform the required tests, if i understand this correctly.

That's exactly what [InternalsVisibleTo()] is usually used for.
Just reference your code assembly in your test assembly, apply the attribute in the code assembly, and you should be good to go.