DefineConstants R25 or REVIT2025 pattern

[ricaun]

Hello @Nice3point

I was looking in your template and noticed that you are using the define pattern with only R and the number with only 2 digits to define the const for the Revit version.

#if R25 
#endif

I wonder if you are willing to consider changing to the REVIT and the 4 digits.

#if REVIT2025
#endif

This gonna make clear what the define is for and gonna make it possible to automate the creation of the defines in the csproj.

<DefineConstants>REVIT$(RevitVersion)</DefineConstants>

I was experimenting with .props to make the creation of the _OR_GREATER and _OR_LOWER on the fly depending of $(RevitVersion) available.

[Nice3point]

it makes sense if we automate the generation of define constants) I've thought about it, but haven't found the time yet

Constants can overgrow and yes we can implement this as in dotnet SDK NETCOREAPP3_OR_GREATER, NET5_OR_GREATER, etc

Maybe you know how it could be improved, I'm open to suggestions

Why I chose R25 instead of REVIT2025 ? Because it's shorter to write.

[ricaun]

I thought you chose R25 because of the configuration. 😁

[Nice3point]

Without automating OR_GREATER prefixes, switching to the REVIT2025 constant is not yet advantageous

[Nice3point]

I'll have time this weekend to think about it, if you've already done something like this or have examples of how to improve it can you share a link)?

[ricaun]

I have a private project with a lot of tests in there, gonna create a new repo with just that DefineConstants implementation and share with you.

[ricaun]

The XXX_OR_LESS does not exist right? Only XXX_OR_GREATER looks like

[Nice3point]

@ricaun yep, OR_LESS can be raplaced as !OR_GREATER. this documentation describes the general idea https://github.com/dotnet/designs/blob/main/accepted/2020/or-greater-defines/or-greater-defines.md

[Nice3point]

Not #if R24_OR_LESS
Use #if !25_OR_GREATER instead

[ricaun]

Done!

• https://github.com/ricaun-io/RevitVersion.DefineConstants
• https://www.nuget.org/packages/RevitVersion.DefineConstants/1.0.0-beta.1

By default gonna work if you add.

<PackageReference Include="RevitVersion.DefineConstants" Version="*-*" />

Gonna inject the DefineConstants based on the value of the RevitVersion in the csproj.

[ricaun]

I suppose adding the version to the package would make more sense.

<PackageReference Include="RevitVersion.DefineConstants" Version="$(RevitVersion).*-*" />

[Nice3point]

Oh, amazing, this package will significantly reduce the .csproj file. But, i'm going to use Microsoft SDK approach 🙈 Like this https://github.com/dotnet/sdk/blob/28bdb8fb185346d172097314d707c57ebb562654/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.BeforeCommon.targets#L213 and auto generate all constants instead of write it manually

[Nice3point]

By the way, can we not add $RevitVersion to the package version, but keep the free versioning 1, 2, etc.. And for example check the name of the configuration. If the configuration starts with R and the end contains 2 digits (this will cover the cases of configuration project R25 and Revit2025), we can automatically create RevitVersion property on these conditions. If the user decides to use Release/Debug configuration, then use the $RevitVersion property specified manually

[Nice3point]

I have a lot of ideas but I need to do some basic things this week after work 🙈 For example, similar to the UseWpf property, make a UseRevitSdk(random name) property that will reference the necessary Nuget packages.

[ricaun]

Oh, amazing, this package will significantly reduce the .csproj file. But, i'm going to use Microsoft SDK approach 🙈 Like this https://github.com/dotnet/sdk/blob/28bdb8fb185346d172097314d707c57ebb562654/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.BeforeCommon.targets#L213 and auto generate all constants instead of write it manually

That's nice, I didn't search for the Microsoft SDK approach. I like that.

By the way, can we not add $RevitVersion to the package version, but keep the free versioning 1, 2, etc.. And for example check the name of the configuration. If the configuration starts with R and the end contains 2 digits (this will cover the cases of configuration project R25 and Revit2025), we can automatically create RevitVersion property on these conditions. If the user decides to use Release/Debug configuration, then use the $RevitVersion property specified manually

That could be done by looking at the configuration and guessing the version, I was messing with that in the other project that has a lot of SDK experiments.

I have a lot of ideas but I need to do some basic things this week after work 🙈 For example, similar to the UseWpf property, make a UseRevitSdk(random name) property that will reference the necessary Nuget packages.

Yes, I was experimenting with creating the Revit.NET.Sdk to add the packages, define, and other configurations.

[ricaun]

Oh, amazing, this package will significantly reduce the .csproj file. But, i'm going to use Microsoft SDK approach 🙈 Like this https://github.com/dotnet/sdk/blob/28bdb8fb185346d172097314d707c57ebb562654/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.BeforeCommon.targets#L213 and auto generate all constants instead of write it manually

Just to update, I add a similar implementation using that dark-magic using target and _ImplicitDefineConstant.

[ricaun]

I'm using the AfterTargets="PrepareForBuild" but I don't know if is the right one, tomorrow I gonna test in some live projects make sure.

The same package not sure, a different one yes.
The RootDir in your image have the RevitVersion and looks odd, in my mind should be bin\$(Configuration) no?

[Nice3point]

RootDir additionally contains RevitVersion so that Nuke can quickly find the right folder to create the installer/bundle. This is just an intermediate folder with all the contents for the desired Revit version

[ricaun]

I see you have a lot of copy in there. In the end, gonna be something like:

📂bin
 ┗📂2021 R21
   ┣📜RevitAddIn.addin
   ┗📂RevitAddIn
     ┗📜RevitAddIn.dll

[Nice3point]

yep, something like this, it's a ready-made folder with all the add-in files. It is copied in its entirety to AppData/Revit/Addins and used to create the installer. Any ideas how to improve this if you see a problem here?

[ricaun]

Looks great! Only this RootDir is not deleted when the user clear the project.
And every bin is clear in the nuke automation, not an issue.

[Nice3point]

@ricaun I was able to write code that generates constants only for configurations specified in the project, not only from version 17 to 25. And it's really cool because we can create a library that covers all the needs for msbuild customisation

[Nice3point]

What else do you think we can add? I tried adding RevitVersion generated from the configuration, but the configuration is empty for the props file, and for the target it doesn't make sense anymore, which is only option to specify it in the project

[Nice3point]

it makes sense to add Autodesk.Revit.DB to the list of default implicit usings

[ricaun]

Nice, I was thinking in a way to remove/control de old version. Using de Configurations is great 👏🏻

[ricaun]

What else do you think we can add? I tried adding RevitVersion generated from the configuration, but the configuration is empty for the props file, and for the target it doesn't make sense anymore, which is only option to specify it in the project

I remember that I have some issues trying that, 😔

[Nice3point]

https://github.com/Nice3point/Revit.Build.Tasks
First build in test variant. I have added to Lookup everything seems to be fine, csproj file became visibly smaller and cleaner. Define Constants generation is awesome 🎉

[ricaun]

Look great! That custom Task looks interesting.

Maybe you should force the Autodesk.Revit.DB to require a package as well.

[Nice3point]

Maybe you should force the Autodesk.Revit.DB to require a package as well.

I thought about it, but decided that people use different API libraries, for example you use Revit_All_Main_Versions_API_x64 which contains quite a few dependencies, I use my own, where each dependency is a separate package. then this approach won't work, and "Revit.Build.Tasks" is used only for revit plugins, and without adding API dependencies it doesn't make sense. Maybe I'll check if we can check Reference instead of PackageReference

[ricaun]

Gonna make some tests tomorrow!

It would be wise to have some kind of RevitVersionMin to force a minimal version for the DefineConst.
Imagine you have version 2021 in the configuration and want to remove the support for that version, if you remove the configuration, the const REVIT2021_OR_GREATER will not exist anymore, or you could refactor to REVIT2022_OR_GREATER.

At least in my RevitVersion project gonna add some kind of RevitVersionMin and RevitVersionMax, to select what defines to use without the configuration. (If you have a better name suggestion, please let me know. 😊)

[Nice3point]

Usually in my commercial projects there is no situation when the lower supported version is removed) only new ones are added. As an option, when deleting the configuration in the project search, look for matches on #if REVIT2021 and if there are still matches, update to a higher version. And if at deletion "#if" block will stop compiling, it will probably start compiling "#else", which belonged to older API versions, resulting in a compilation error, which can be quickly fixed.
No better ideas so far, but your option with min, max makes sense)

[Nice3point]

@ricaun Don't know why yet but the package breaks the dotnet pack, targets just don't execute, don't know the cause or haven't encountered it?

[ricaun]

I didn't test that! Is not some limitation of the Tasks.?

[Nice3point]

I think I realised that the problem is in implicit Using, they are not restored when the project is packed. Also sometimes they are not included in GlobalUsings.g.cs. I have not included them in templates yet and specified them explicitly. Maybe this is a limitation of dotnet sdk