Is GetProjectReferences broken?

[djanosik]

I've tried to use Automaty to replace Scripty, but it fails to load project references. The referenced assembly is loaded from bin/Debug/Assembly.dll, but it's in fact located in bin/Debug/net451/Assembly.dll.

[Dresel]

I'm sorry but as stated in the description only .NET Core based projects are supported (targeting netstandard or netcoreapp).

[djanosik]

.NET Core (SDK) based projects targeting full framework are not supported? Why?

[djanosik]

I have created a sample project and I see that SDK based projects targeting full framework are supported. It works quite well, but there is a problem with projects targeting multiple frameworks. In that case the path to referenced project assembly is not resolved correctly.

Sample project: Fiddle.zip

[djanosik]

Also it looks there is an issue when the referenced project targets netstandard2.0.

Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.

[Dresel]

I did not test it with multiple framework targets, but it seems additional logic has to be added to GetProjectReferences to support this.

To support 2.0 I have to deploy a new version of Automaty.DotNetCli which also targets netcoreapp2.0.

[djanosik]

Ok, do you have time to fix it? Or should I send PR?

[Dresel]

Updating Automaty.DotNetCli to netcoreapp2.0 should be no problem, but I'm happy if you have some time to investigate the multiple framework target problem because that's something I can't fix within the next days as I'm busy (don't know how important this feature is for you).

This is the place to start with, you have to deal with the MSBuild api, read TargetFrameworks and somehow decide which target to use. Debugging Automaty is quite cumbersome though.

[Dresel]

Thanks for your contribution, I've merged your pull request and already uploaded a new version of Automaty (Core and DotNetCli). Let me know if this works for you.

May I ask what you are going / trying to implement with Automaty? Is it going to be open source?

[djanosik]

It works now, thank you!

I will probably use it in https://www.dotvvm.com/ and related projects. I want to replace T4 templates and Scripty. T4 templates don't run on build and Scripty is not compatible with .NET CLI. Automaty looks really promising. But I am not sure whether it's good idea to use plain C# files. Generators are "build-time" and should not be compiled into project assembly.

[djanosik]

Now I see why full .NET is not supported. Not all dependencies are loaded from NuGet packages and therefore are not available during compilation of generators. Eg. you can't use System.Linq in generator on full .NET framework. This should be mentioned in docs.

[djanosik]

@Dresel Would it make sense to always import NETStandard.Library?

[Dresel]

Generators are "build-time" and should not be compiled into project assembly.

Well you could set Build Action to None but I'm open for other suggestions.

This should be mentioned in docs.

I thought that It supports (only) .NET Core based projects is enough but we can add a more detailed explanation here.

@Dresel Would it make sense to always import NETStandard.Library?

You mean for .NET support?

[djanosik]

Exactly. If you import some set of standard libraries, it would work much better with full .NET.

[djanosik]

Hmm, Automaty works without issues in projects targeting .NET 4.7, but not in projects targeting .NET 4.6. Maybe because .NET 4.7 references all assemblies included in NETStandard.Library?