Multiple dotConnect versions on site - development/build server/deployment

[mko]

Hi,

we are trying to move away from installing dotConnect in our production environment towards delivering the runtime assemblies packaged together with the web applications. Upgrading to a new version is a huge headache when it can affect hundreds of applications. We could use some assistance .

Following the proposed solution:

• Development machines: Full installation of the current dotConnect version including Visual Studio plugins. Including the license.licx in the projects so the license later gets compiled into the resulting assemblies by the build server. Setting "copy local" to "true", so the DLLs are packaged with the application.
• Build server: Minimal installation of multiple different relevant dotConnect versions. Removing all policy files from the GAC. The license should get compiled into the application assemblies.
• Production servers: No (or old) installation of dotConnect, relevant DLLs are deployed in the bin folder along with the application assemblies.

The main problem here seems to be the build server (different dotConnect versions needed), especially regarding the license issue (to my knowledge dotConnect has to be installed so the corresponding license can be compiled into the assembly). We have a site license.

Questions:

1. Is this a possible and sensible solution for us?
2. Are multiple minimal dotConnect installations on the build server even possible? It doesn't seem so, since the dotConnect setup uninstalls the previous version.
3. Does dotConnect have to be installed on the build server, so the license can be compiled into the application assemblies or is there a workaround?
4. Does the installed dotConnect version have to match the version used during build, so the license information in the application assemblies is valid?
5. What exactly has to exist on the build server so the license information can be compiled into the application assemblies when adding a licenses.licx file to the projects?
6. How else would we best manage the build server?

Another possible solution for the build server (in my head) could be:

• "Compiling License Manually" (as described in the licensing document) ONCE for every new version
• Have the developers include the resulting .license file in all of the projects using this dotConnect version
• Manually installing all relevant dotConnect assemblies in the GAC of the build server

The first solution would be preferrable, but anyway:

1. Would this be a possible solution?
2. Can the .license file be compiled once for every dotConnect version or does it have to be compiled once per application? That would be a problem.
3. In which situations would the licenses.config file be required? If the .license file can not be added to the runtime assembly/executable? What about unit test runners and w3wp.exe?

Thank you very much in advance for assistance!

[Shalex]

1. Is this a possible and sensible solution for us?

Yes, this is.

2. Are multiple minimal dotConnect installations on the build server even possible? It doesn't seem so, since the dotConnect setup uninstalls the previous version.

They are possible: for this, you should manually remove the HKEY_LOCAL_MACHINE\SOFTWARE\Devart\Installed Products\dotConnect\Net2\PostgreSql key for x86 operating system and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Devart\Installed Products\dotConnect\Net2\PostgreSql key for x64 operating system before each new provider installation. Additionally, you should remove all policy.*.Devart.* files from GAC2.0 and GAC4.0.

3. Does dotConnect have to be installed on the build server, so the license can be compiled into the application assemblies or is there a workaround?

There are two alternative ways:
3.1. installing the provider on the build server
3.2. no provider installation on the build server, but building the license resource on the development workstation and adding the result 'exe.licenses' (or 'dll.licenses') to project as an embedded resource

4. Does the installed dotConnect version have to match the version used during build, so the license information in the application assemblies is valid?

Yes, it does.

5. What exactly has to exist on the build server so the license information can be compiled into the application assemblies when adding a licenses.licx file to the projects?

See the point 3.

6. How else would we best manage the build server?

It looks better to compile the license resource manually not to install multiple provider versions on the build server. But your current approach is also possible.

a. Would this be a possible solution?

Yes, it would be.

b. Can the .license file be compiled once for every dotConnect version or does it have to be compiled once per application? That would be a problem.

The generated .license file is specific to particular provider version, application name, and, if any, target *.exe files.

c. In which situations would the licenses.config file be required? If the .license file can not be added to the runtime assembly/executable? What about unit test runners and w3wp.exe?

You should add the names of the following processes to licenses.config:
a) w3wp.exe (if the web server, where the web application is deployed, is IIS)
b) devenv.exe (if running NUnit tests within Visual Studio)
c) nunit.exe (if running NUnit tests via separate tool)

In this case, the chain of calls which leads to opening a connection is w3wp.exe (or devenv.exe or nunit.exe) -> YourWebApp.dll -> Devart.Data.PostgreSql.dll.

For more information, refer to http://www.devart.com/dotconnect/postgr ... g.html#lib ("Class Libraries Support").

JIC
Our license validator looks for the valid license in the following way:
*.exe -> FirstCalledClassLibrary.dll -> ... -> LastCalledClassLibrary.dll -> Devart.Data.PostgreSql.dll
The valid license for *.exe has to be available at any level of this chain: either built in *.exe (licenses.licx), or added to one of the used class libraries (licenses.licx + licenses.config with the name of *.exe).

[mko]

Thank you very much for the quick, elaborate and competent response! I'll report back if I run into any more issues .