Has anyone been successful in building a NetStandard-2.0 or Net-5.0 plug-in?

[m.cicognani]

Has anyone been successful in building a NetStandard-2.0 or Net-5.0 plug-in?

I've read in a couple of post where, in theory, netstandard-2.0 should be compatibile with net framework 4.6 and above, so, always in theory, it should be possible to target netstandard-2.0 for Revit plugins.

But I tried, and didn't succeed, even with a very basic plugin, basically just the output from the visual studio wizard...

I understand this is not a supported practice, but given the 'big' framework will stop with 4.8, and a bunch of new technologies are already available on net core / net standard / net 5, and with net 6 already in RC state... I believe it's worth to understand the situation with Revit and make some experimentation...

Does anyone want to share its experience?

[RPTHOMAS108]

Out of curiosity I had a go at this the other night but it was too painful to progress.

My main issue was the usual one about the addin not finding the assemblies due to the addin assembly being elsewhere from Revit.exe.

Fine you say just use AppDomain.AssemblyResolve Event, not if one of the assemblies you are looking for contains this event. I think there is likely a simple fix in the config file that goes with Revit.exe but I'm not messing about with that.

Also the debugger wouldn't hit the breakpoints set which was a separate issue that I couldn't be bothered to understand.

"The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core."

Says it all really.

On the whole I concluded that if I got it working there would be 0 certainty of it working on another platform due to all the elaborate things being done to get it working on this one (Windows).

So just wait until there is actually stated support for it perhaps I'm now thinking. Probably easier to use VB6 code to write Revit addins (where there is a will there is a way, but there's no will here).

[sahin.ikbal]

dotNet 5 or 6 feels so exiting for developers, but unfortunately Revit feels like not willing to go there so easily.

As Stated by RPTHOMAS108 (where there is a will there is a way, but there's no will here)

[jeremy_tammik]

There is definitely both a will and way. The latter is significant and non-trivial. The former has been formulated and is being continuously discussed internally by the development team. More on both from the factory and The Building Coder here:

https://thebuildingcoder.typepad.com/blog/2021/01/face-triangulation-lod-net-5-and-core.html

[RPTHOMAS108]

Yeah I was referring to my 'will' to continue with the above unchartered experiment really. I have high confidence Autodesk already have a roadmap for this change and are likely already on it, navigating around the early potholes etc.

Probably it raises more significant questions for Autodesk in terms of where they see the future of Revit as a desktop application (what 'new' features that .Net has will they be taking advantage of if it remains a desktop app). From my outsider view I see a program written in an unmanaged language anyway (so will likely always contain platform differences) are those reduced by incorporating .Net 5, I don't know enough about that. Then there is the fact that .NetFramework isn't going to cease to exist it seems.

So then if the motivation for the change is only to be technically compliant with latest .Net then it is probably a lot of work for little visibility of that effort (for a Revit user on Windows at least).

Interesting times of uncertainty.