Open natanielcz opened 4 years ago
Well, Reinforced.Typings.settings.xml
controls MSBuild flow. I have already moved everything that I could into code, so in Reinforced.Typings.settings.xml
there are only options that are required for build process and are tightly integrated into it. E.g. RtDisable
bypasses RT on MSBuild level. I can move target file/target directory to code, but I think it will ruin CI/CD processes of many people that are using RT.
We could keep compatibility:
What do You think about that? :)
Env variable? So if you are building several projects with RT on same CI/CD server?... Then what? Or you suggest to specify env variables for MSBuild directly? Then.. meh.. how would you do that in Visual Studio?
Am I right that you suggest intentionally to add configuration file for every setup? Well, it will negatively affect learning curve. Now you just install package, add attributes, press "rebuild" and it works. After suggested change - you will have to create configuration file somewhere. From another point it may work, yup, because you anyway have to create .xml manually. But we cannot discard XML (see 1), therefore user will have to create 2 files. I think it is too much. RT already has not so much users - let's at least do not scare them :)
At least for now
P.S: Moreover, if you are using files separation (aka RtDivideTypesAmongFiles
) now - files locations are already being read from code de-facto
What do You mean by locations are being read from code?
Hi,
What do you think about defining configuration by default in a class which implements i.e. interface
IReinforcedTypingsConfiguration
? In this class, we could define settings which we are setting currently but also everything that is currently inReinforced.Typings.settings.xml
. And additionally, we would have all assemblies used in the current project.