Creating external subroutines for multiple VB programs

[JoeW]

I am writing multiple programs and creating subroutines that are used in different programs. I have put these subroutines in modules but I think that only creates internal subroutines. What I would like to know is how to create a set subroutines (probably in multiple modules) and then be able to link them into different programs. I would like see some examples or have links to that illustrate the procedure.

[jmcilhinney]

That's exactly what libraries, i.e. DLLs, are for. All the .NET Framework types are declared in libraries and you reference those libraries in your project to gain access to those types. That's exactly what you need to do with your own common types.

You should start by creating a new solution and, in it, create a new library project. If you need functionality that relates specifically to Windows Forms then you should create a Windows Forms Control Library project, otherwise create a Class Library Project. The former includes a few extra Framework references but you can still add those yourself to the latter for the same effect. The IDE will add a user control or a class to the project by default, just as it adds a form to Windows Forms Application project by default. If all you want is modules then you can delete that type from the project and start adding your own types as required.

Once you're done, you can build your project and it will output a DLL file, instead of the EXE that an application project would. You can now reference that output in your other library or application projects to access that common functionality. I would suggest that you do that in one of two ways:

1. If you want to reference the DLL directly, I suggest creating a dedicated folder for built libraries and referencing it in that location. Any time you make changes to the library, rebuild the library project and copy the new output to that folder, then rebuild any application projects that need to use the update. Note that you should be placing Release builds of your libraries in that folder rather than Debug builds. Only use a Debug build if you specifically need to debug.

2. In the solution containing your application project, add the existing library project. The project folder is not copied but simply referenced in its existing location. Now that your application solution contains both projects, you can reference the library project rather than its compiled output. This allows you to debug both projects at the same time and make changes to the library project while doing so. You can add the library project to as many other solutions as you like, so be sure to make changes that will be OK in all other applications projects too. When you build your solution, it will build the library project too, so the application will get a new DLL each time and it will also use either Debug or Release based on the build configuration of the application.

I would probably suggest going with option 2 if your libraries are a work in progress and will change and grow as you build the application. If you already know what the library will contain and that is unlikely to change much, if at all, go with option 1.

[JoeW]

Thanks jumcilhinney
I am organizing the subroutines by physical functions, graphics, and constants. I think your option 2 looks good. I'll have to write some sample programs. .NET is a lot more learning than before. Is there anyway of doing a copy and paste of already written modules into a dll?

[DataMiser]

Another option if you do not want to go the dll route is to create templates from the classes, modules or forms that you want to reuse and then you can quickly add a copy of them into your project at design time and have them compiled into the main program.

[JoeW]

Thank you DataMiser. I will look into templates.

[jmcilhinney]

Another option if you do not want to go the dll route is to create templates from the classes, modules or forms that you want to reuse and then you can quickly add a copy of them into your project at design time and have them compiled into the main program.

That is generally a bad idea except in very specific circumstances. If it is exactly the same functionality in each case then that functionality should exist in one place only. Otherwise, if you find a bug then you have to go and change that code in every place you have used this template. There really is no reason to "not want to go the dll route". In certain specific circumstances, in may not be the best option but in most cases of common functionality across multiple applications it is absolutely the best option so not wanting to use the best option equates to wanting to be a bad developer.

[DataMiser]

Well lets say you have a class or module that has been thoroughly tested, works just fine as is and it is fairly small but may be used in many projects. Creating a template from it allows you to include it and compile it into your exe. No need to include additional files, works without a hitch. On the other hand you could create a tiny dll and include that as an extra file. Result is more overhead, slower execution and slightly more effort to deploy.

As to your comment about being a bad developer, I could just as easily say that adding stuff that is not needed and/or not used by the program equates to wanting to be a bad developer. The fact is that if you have several classes and modules you may use some in one project more in other projects, different ones in other projects. Sure you can put them all in one dll which adds bloat to every project you do this way or you can create lots of little dlls and include only the ones you use in that project but then you have a lot of additional files. If instead you create templates and add only the ones you use to your project then you have a single exe file that does it all without the extra overhead of a dll and without the extra bloat of modules or classes that are not actually used in that project.

There is a time and a place for both options and it was presented as an option which of course is up to the person writing the code how they would like to proceed. As for the bug part, ideally you thoroughly vet the class or module. I have some that have been in use for this way in VB6 that have been adding into projects for almost 20 years now and not once have I ever had to go in and modify them due to a bug in the template code. On the other hand if at some point you need to modify the code of the dll there is a chance to break existing programs that use the dll, with templates the code is a copy of the template so changes can be made as needed for a specific project without changing the actual template and not causing any potential issues for other projects.

[Shaggy Hiker]

Can you back up that slower execution statement? I don't believe it is true.

I'm not thrilled with the idea of templates. There are times when they do make sense, but the place where they make the most sense is where you KNOW that you will be changing them from one project to the next. I've used that approach in a few narrow cases, but if I ended up using a template more than twice, I redesign them as dlls.

There's a further issue that confounds any advantage that templates provide, which is maintenance. All programs require maintenance. If you can get a well tested dll, then you can isolate that functionality to the dll and the maintenance needed is also divided. This doesn't just make the maintenance a bit easier, it will push you towards a more maintainable design. With a template, there is always the temptation (or templatation) to take the easy route of just altering the template to cover some one off need. Over time, this will tie the template more and more into the project until it becomes inseparable. While easy in the short term, it works against you over time, so long as the project is large.

I've been working on a plug-in based system. Over the years, I've come to realize that dividing things into dlls imposes a certain discipline that makes the project, as a whole, more maintainable. Unfortunately, I have yet to be able to truly articulate (as you can see) the design principles regarding dlls that bring about this improvement.

[JoeW]

Thank you both Data Miser and jmcihinney for your comments. I see that both are valid in particular applications. I am not a CS or CSE person but a physicist that wants to automate trade studies and system analysis and report generations. Until the middle of the 00s I never used VB. Before I had use HP Basic, FORTRAN, PL-1, FOCAL. I see jmcihinney DLLs method is useful for pulling information from various databases I want to create as the way I might like to access them may change as I develop the program while the use of a template looks good to me for physical equations that doesn't change like Q-function, Airy functions or even antenna patterns. I just need to learn how to do both methods. VB.NET is so large and spread out, it is hard to find details beyond the introduction material.

If either one of you know of a video that illustrates either technique please let me know.

[Shaggy Hiker]

There's nothing to show about a dll. JMC described all you have to do in his first post: Create a project of type Class Library. Otherwise, it's the same as any other project.

[DataMiser]

I can't say for sure if the execution is slower in VB.Net since it is not a true native exe you are creating any way, it may be little to no difference other than the larger file size and additional file that needs to be loaded, with SSDs that is less of a factor. Keep in mind I have been using the template approach in VB5 and 6 going back to the 90s. In these cases those templates are small and get compiled to native code so they are most definitely faster than linking to a dll and have less overhead. I do of course use dlls as well and the occasional user control where needed.

[DataMiser]

To create a template you just save the form, class, module or project in the proper section of the templates folder. When you choose to add a new item to your project the template should show up in the list. I haven't been using VB.Net much lately, I used to use it a lot for Windows Mobile stuff but that pretty much dried up. Some of the templates I had for it were classes that linked to 3rd party dlls and set the various parameters for barcode scanning and audio features as well as some basic forms like login and settings that would be used in most applications so when I started a new project I just choose the template as my project type and all of that was there in the newly created project. I have a few classes, modules and project types for VB6 saved as well. Been I while since I used those so can't remember much about them. Lately I seem to be doing more for Android than Windows so have been using different tools.

[Shaggy Hiker]

In these cases those templates are small and get compiled to native code so they are most definitely faster than linking to a dll and have less overhead.

I'm not even sure that is true. .NET isn't an interpreted language. It is also compiled to native code, it just does so when first run. In the one, significant, head to head VB6 vs .NET comparison I have done, there was no appreciable difference in either direction.

[jmcilhinney]

To create a template you just save the form, class, module or project in the proper section of the templates folder. When you choose to add a new item to your project the template should show up in the list. I haven't been using VB.Net much lately, I used to use it a lot for Windows Mobile stuff but that pretty much dried up. Some of the templates I had for it were classes that linked to 3rd party dlls and set the various parameters for barcode scanning and audio features as well as some basic forms like login and settings that would be used in most applications so when I started a new project I just choose the template as my project type and all of that was there in the newly created project. I have a few classes, modules and project types for VB6 saved as well. Been I while since I used those so can't remember much about them. Lately I seem to be doing more for Android than Windows so have been using different tools.

I think that I may have misunderstood what you meant when you were talking about templates. I didn't realise that you meant project/item templates in VS itself. I would still suggest that they are providing a different function to DLLs though. You would still have to fix any bugs multiple times in every project that had used a template, rather than in one place for a library. Also, the idea of a template is that it provides a common starting point and you customise from there. In this case, the OP seems to be talking about exactly the same functionality in multiple projects. That is pretty much exactly why libraries exist. This is still a case of using the best tool for the job and, in my opinion, a library is that tool in this case. Any talk of speed differences is just silly in this context, given that such a large proportion of any such project is going to be contained in the libraries that make up the .NET Framework anyway. On the average system these days, I'd expect any difference to be barely measurable and certainly not perceptible to the user. Writing the most maintainable code possible should be the first priority and performance should only be a consideration if there is the potential for significant differences. I would always prefer imperceptibly slower code over code that is harder to maintain - even potentially harder.