Unity separate generator project

[AlonTalmi]

Solves #138

The main differences between Jab.Unity and Jab.Roslyn3 are:

• Doesn't generate the attributes class in assemblies (and because of that doesn't require RegisterForPostInitialization)
• Uses CodeAnalysis 3.8.0
• Ignores when attribute types are missing
• Skips Unity builtin assemblies (Used VContainer approach )

I also moved the generator scripts to a separate directory so they're not imported as part of the Jab.Common
(Which for some reason required me to add more pragma warning disable for RS1001)

In order to use inside Unity follow: https://docs.unity3d.com/Manual/roslyn-analyzers.html
Also requires the Jab.Attributes.dll

[pakrym]

Is there a chance we can adapt the main project to detect unity and adjust the logic?

Uses CodeAnalysis 3.8.0

Does unity define any MSBuild variable we can use in build.targets to downgrade the CodeAnalysis version?

Ignores when attribute types are missing

Why is this needed?

[AlonTalmi]

Uses CodeAnalysis 3.8.0

Does unity define any MSBuild variable we can use in build.targets to downgrade the CodeAnalysis version?

Unity has it's own compilation process and only accepts precompiled generators as dll unfortunately...
Apart from downgrading to CodeAnalysis 3.8.0 I guess everything else can be achieved by detecting if the assembly references a Unity library and adapt

Ignores when attribute types are missing

Why is this needed?

Because I disabled the attribute class generation because CodeAnalysis 3.8.0 doesn't support RegisterForPostInitialization, instead the user has to reference the Jab.Attributes.dll himself.

Which to be honest I like better anyhow, why do you generate the Jab.Attributes class in every assembly in the first place? seems wasteful (Unity projects very often have 150+ assemblies)

[pakrym]

Unity has it's own compilation process and only accepts precompiled generators as dll unfortunately...

Gotcha, thank you for the context.

Which to be honest I like better anyhow, why do you generate the Jab.Attributes class in every assembly in the first place? seems wasteful (Unity projects very often have 150+ assemblies)

Usually, you only add JAb to one or two assemblies that need service provider. But I can see how Unity make this case worse.

I'm not a fan of skipping assemblies by name and try-catching on types not found. What do you think about filtering out assemblies without known types early on in Generator.Unity? That way we don't need to hardcode any module names and the rest of the generating code can assume types are there.

[AlonTalmi]

Usually, you only add JAb to one or two assemblies that need service provider. But I can see how Unity make this case worse.

Ahh also something I forgot to mention, Unity doesn't let you add a generator only to specific projects only the entire Unity solution 🙃

I'm not a fan of skipping assemblies by name and try-catching on types not found. What do you think about filtering out assemblies without known types early on in Generator.Unity? That way we don't need to hardcode any module names and the rest of the generating code can assume types are there.

You mean by adding compilation.GetTypeByMetadataName(_typename_) != null inside the Jab.Unity specific generator?
Yeah sure, I can make the changes after you confirm.
Can I add a method for CheckAllTypesExists inside KnownTypes?

And I have no strong opinions about skipping assemblies, I'll remove it if you prefer :)

[pakrym]

You mean by adding compilation.GetTypeByMetadataName(typename) != null inside the Jab.Unity specific generator?
Can I add a method for CheckAllTypesExists inside KnownTypes?

Yeah, something like:

if (!KnownTypes.HasKnownTypes(compilation, compilation.SourceModel))
{
  ... skip the module
}

Feel free to check for a single type inHasKnownTypes. Either all of them are there, or none is.

[AlonTalmi]

Feel free to check for a single type inHasKnownTypes. Either all of them are there, or none is.

Isn't return sourceModule.ReferencedAssemblySymbols.Any(s => s.Name == JabAttributesAssemblyName); enough to be honest?

[pakrym]

Ah, right, we don't care about embedded types in this case.

[pakrym]

nit: remove

[pakrym]

Is this correct? How will users get this dll then?

[AlonTalmi]

Unity users have only 2 options: downloading/building and dragging manually the dll into their Unity project or using an npm package (which I created here)

Unity doesn't support Nuget unfortunately

[pakrym]

What about https://docs.unity3d.com/Manual/upm-git.html ? Do you know what needs to be added to this repo for unity customers to be able to reference it via a git reference? Or should we add a minimal jab npm package with the generator dll only?

[AlonTalmi]

If you can build the Jab.Unity.dll and Jab.Attributes.dll into any directory in this repository then we only need to add a package.json like this inside that directory and then users can install it using:
https://github.com/pakrym/jab?path=the_path_to_that_directory

[AlonTalmi]

Ohhh and we need to add Unity specific meta file for each dll by opening them inside Unity

[pakrym]

Is the meta file generation a one time operation or is it required for every new dll build?

[AlonTalmi]

One time

[pakrym]

Thank you @AlonTalmi!

[AlonTalmi]

Thank you @pakrym 👍
I would like to also help create a Unity npm package if you want.
If so, do you have a preference where the package directory will be?

[pakrym]

I'd love it!

Can we have the package definition right in the https://github.com/pakrym/jab/tree/main/src/Jab.Unity and then have CI do building and publishing? Happy to help with the CI part.