I wasn't aware of the power of all those design patterns. This makes a great toolkit even greater. This discussion made me realize I have to take a closer look at all those different design patterns.
I tried to add the new method as a property node instead of a normal method. That's why I couldn't find it. Having these templates for every design pattern makes them very easy to use.
I downloaded the new version and it looks perfect to me. Thanks for updating the templates so quickly.

Thanks for the feedback and for updating the templates.
When creating the screenshots I kept the error handling mechanism of the original read. I probably didn't pay enough attention on error handling, just wanted to point out the difference in read by value or by reference issue.
The Reference Variable Design is indeed a good alternative if working with large datasets. I wasn't aware of that. One disadvantage of that design pattern however is that the GDS can't create property methods for the referenced variables. They are not in the "Data Fields/Attributes" list of the Create Method Dialog. This makes it more cumbersome to create property methods for this type of attributes.

When I create new property node methods for a GOOP400 class using the OpenGDS they look like this :
The Write method gets the reference to the data and then modifies it in place.The read method gets a complete copy of the data and unbundles the wanted element. When the object contains a lot of other (large) elements I would like to avoid copying the entire data to unbundle just 1 element. This means also getting a DVR to the object and unbundle the element inside an in place element structure, as shown here :
In LabVIEW 2017 and above I could even use "Allow parallel read-only access." to make sure it's read-only.
Currently I modify such read methods manually each time I create a new one. I know I could update the template but I was wondering if there is any good reason not to do this. Or what is the reason why the original OpenGDS is reading by copying the entire cluster?

I didn't solve that problem with the popup dialog. In stead we are using the CLI of LabVIEW 2018 for contiuous integration. This is installed with LabVIEW 2018 as a shared resource and is backwards compatible with older versions. I believe back to 2014.

Unfortunately the video "2018NIWEEK_332_Samual Taggart_Test Strategies for Project Success" crashes at 20:33. It seems something is wrong with the file. I downloaded it again but that doesn't help. Is anyone else experiencing the same problem?

It's a great tool.
I noticed that I can run it from the command-line. By using the following command:
"MGI Solution Explorer.exe" <path_to_lvsln> -B
it will open the tool and start the build process.
Unfortunately the first thing that happens is a warning dialog asking me to make sure all changes are saved before proceeding.
Is there any workaround to avoid this dialog so we can use the tool in our continuous integration and let it generate (nightly) builds without any user interaction?