I'm somewhat new to deploying ClickOnce manifests, first off. I know the basics of how to publish to an app server, which then lets every use the newest version (after setting to check for updates before running the application).

We have multiple VB.Net applications stored on our app server, that cover a lot of different areas of the company. However, all of them connect to our Oracle database in the same way. So, my thought was to create a DLL containing commonly used functions, such as decrypting and reading our connection string, among some very common SQL functions/statements that we use a lot. Then, instead of copying and pasting the same code into each .Net program, it would be stored in one place. Of course, the major benefit to this would be that if we change the method we use to connect to the database, or need functions modified/added, we don't need to open each program, paste it in, and .republish

So, I did a test where I took a program that I wrote, added the DLL to it and tested it out. It works great. Then I took the source code of the DLL, made a change to show a message box at the beginning of a function, rebuilt the DLL, and dropped it in place of the copy that was being referenced in the test program. When I run the program, it's still using the original DLL without the message box code.

My question is, how could I accomplish what I would like to do without having to republish each and every .Net program that uses this DLL whenever a change is made to it?

No...all of the applications that will be using this DLL are standalone Windows Forms applications. The DLL is just that, a DLL file on our application server that will be referenced by each application. When the DLL gets updated, I need a way for all of the applications to use the new version of the DLL rather than the one it was compiled with.

In my testing, I built a dll that opens a message box as you stated above. Then I added a reference to the dll, added an Imports statement. And used the dll. I updated the dll, and copied the new dll to the folder that contains the .exe file, then ran the .exe file again and the MessageBox contents were changed. Please provide more details about the process that you used.(step-by-step).

  1. Publish applications with references to the DLL using ClickOnce. They are stored on an app server, separated into different folders (named after the solutions names). So, at this point, for example, we'll say I have five directories on the app server under \appserver\apps\, one app in each directory.

  2. The DLL file is stored in the \appserver\apps directory.

  3. I run any one of the 5 applications, they work as expected.

  4. I make a change to the DLL code and copy it over the existing one located in the directory \appserver\apps.

  5. I run any of the 5 applications again, and the changes to the DLL do not show up.

  6. At this point, if I republish the applications, they will then use the new DLL code I added in step 4. This is the step we want to avoid, because in actuality we have somewhere in the neighborhood of 25 to 30 different applications that we would have to repubish when we make a change to the DLL. Or, we would have to copy and paste the DLL into each app folder separately.

DLL files are placed either in the systemfolder (/windows/system32/ dependent on the Windows-version) or they can be placed inside the same folder as the executable (.exe) file.
When your application is started it will try to find a DLL-file with the correct name and version and when it can'nt find the correct version in the executable folder, it will try to find it somewhere else (possible in the system-folder), untill it finds the correct version of the DLL-file.

Where searching is performed depends on the Windows version an how Windows is set up.

Your point 5 shows that the application do find the old version of your DLL-file, so it must be somewhere on your machine.

There isn't a way to tell the program not to use a local copy and to use the copy stored on the app server always? This is the behavior I am looking to achieve, so that if we do update the DLL, we should be able to replace the single copy on the app server.

I think I may have found another solution, which is to load the DLL from the app server at runtime, and set up an interface to add into the source code. Still copy and paste per program but less maintenance should we make any major changes to any of the functions.

This article has been dead for over six months. Start a new discussion instead.