![]() ![]() ![]() If you are not planning on debugging them, then why clutter that bin folder with them? Also, every now and then I am asked to obfuscate the code (I know, don’t ask why), but if that’s part of the Release routine, then I CAN’T debug the Release code, and that necessitates that I have Debug and Release configurations. Why do I care for Debug/Release? You might want to do things like disable XML/PDB file creation for Release builds. That might be as many as 8 Configurations if I need to carry Debug/Release for 2021/2020/2019/2018. build your MSI, referencing assets (DLLs) from folders on a drive, rather then dynamically linking them from Visual Studio solution directly.Īnother thing that greatly annoyed me with Configurations was the fact that now I basically either had to give up the idea of having a Debug/Release Configurations, or I had to create them for each version of Revit.build all of your Configurations, copy these DLLs to different locations based on a Configuration.Now, you have a pickle because you have to do that in two steps: If you are using things like Configurations, then you really have just a single DLL/project, but you might want to have your installer reference different versions as you would want it to copy them to different locations. These allow you to reference an asset or a project. The real benefit of Shared Projects comes into play when we start dealing with things like Setup projects aka. The answer is, YES! OK, so I agree, a Post Build event or Target FrameworkVersion configuration that looks like the one below might not be sexy, but it’s not end of the world. Is there a real benefit to this approach?” Someone might say: “Well that’s nothing special. This approach makes it easy for me to have post build events that copy resources (*.addin manifest files) to specific location, and I don’t have to use “if Configuration = 2020 copy to 2020 location” type code. The idea is that all shared code, is contained in the archilabSharedProject, but all resources that are unique to specific version would be contained in that version’s project. What does that look like:Īs you can see above there is an “archilabSharedProject” project, and there are different projects for “archilab2021”, “archilab2020” etc. Now, whether this is the “correct” approach for Dynamo is a completely different discussion, because as we all know it, Dynamo doesn’t make anything easy, but let’s assume it was the correct approach. I have recently switched Dynamo package to use this approach. you can just do that in different projects. Shared Project approach actually allows you to build different DLLs for each version, where each DLL has the Shared Project embedded into it, but now instead of using Configurations to control Post Build events, References, Dependencies, Setup projects etc.There is still just a single project (DLL), that is compiled and post processed based on whatever Configuration is currently selected. Configurations build different versions of the same code, based on the selected Configuration.How is that different than Configurations: The way it works is that each project (DLL) that references the Shared Project would have the code contained in it, incorporated right into it. A Shared Project, is basically shared source code. From the sound of it, you might think that it’s some DLL that is shared across multiple projects, and that it contains code that would be used by these projects. Let’s first examine what a Shared Project is. This has been added as a new feature back in Visual Studio 2015, but I haven’t really heard of it until few months ago. This in fact might be the best solution for their unique problem, but I thought that I share another approach that I have learned recently. Now, don’t take this as I am telling you that Matteo is wrong. The only reason I am even touching this subject is because I have recently saw a post on Speckle Blog, that discussed this same approach, and they opted for Configurations. At the time I thought that Configurations was the right way to go, but as you can guess, I no longer think that’s true. Basically, the issue was that I needed to maintain multiple versions of my Revit plugin, to match multiple versions of Revit that I wanted to support. Obviously, I wrote about this topic some time ago. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |