In one of
my previous post (link) I mentioned that devart needs to be licensed and it has
a simple tool built in to visual studio which is easy to use and works (just
click to button and don’t care:)). After few weeks I changed my mind and say,
don’t use this tool (or use it only in special cases). I try to explain why in
this post.
Devart
licenses are per developer, it doesn’t matter on how many machines you install
them. You should consider the following scenarios:
- You install devart
on every machine where you run your application. After installing devart, it
sits in GAC and you don’t need to do anything if you run your application only
on this machine (or other machines where devart is installed). In this case the
application needs to be compiled and
run on a machine with installed
devart. This is not very useful scenario, but for some controlled environments
or web applications could be acceptable .
- You install devart only
on development machines, here is happening the compilation of application. On
the machines where the application runs, devart is not installed. This is
better and this is the case where the tool from visual studio from my previous
post could be usefull. The key here is that the compilation needs to be done on a machine with installed devart.
You could have a big development team, not everybody is working on data access
layer, if there are developers without installed devart, they won’t be able to
make release of the application. Another issue is with CI or build server,
during the build process the compilation is happening usually on build servers
which is not the development machine. Devart should be installed there too. If
you install devart on the build server, the configuration of build and
production environment would be significantly different (in this case on the
production devart is not installed). This is not acceptable for me.
- You install devart only on the machines of those developers who work
directly with devart. Under working directly I mean they create new projects
which are referencing devart assemblies. After the project is created (and set up for licensing), it can be used
by other developers without devart installed locally on their machines. There
is no need for install it to neither build server nor production environments.
I think this is the most expected and desired behaviour, unfortunately it is
not supported with devart tooling and is poorly documented...
Below is my
way to option 3.
First of
all let’s see what is the visual studio plugin doing. It searches for direct
references for devart assemblies in the projects in solution, after clicking to
“Fix” button, it creates a file with .licx extension, this file is included in
the project and is marked as embedded resource. During the compilation lc.exe
is running which is searching for licx files and compiles them to binary
license files which will be embedded to final assembly too. Lc.exe is a
standard Microsoft licensing tool, more on this here: http://msdn.microsoft.com/en-us/library/ha0k3c9f%28v=vs.110%29.aspx
. If the lc.exe tool is running on a machine where devart is installed, the
binary license file is created correctly, otherwise not and the application
will end with error messages that there is a problem with devart installation
etc.
What we
need to do is to precompile licx files to binary files on a development machine
and include these precompiled license files to projects as embedded resource
(and don’t forgot to remove the .licx files from the project, because if lc.exe
finds it during the compilation it will recreate the precompiled license file).
Personally I wouldn’t use the built in VS tool and won’t add licx file to
project at all, I add to project only the precompiled binary license file.
I have a
web application project which references 40 class library projects. 12 of the
class library projects are referencing devart directly. The web application project
has a legacy DAL code– it references devart too. I precompiled manually the
licx files in those 13 projects:
- licenses.licx
file contains this: Devart.Data.Oracle.OracleConnection, Devart.Data.Oracle,
Version=8.2.103.0, Culture=neutral, PublicKeyToken=09af7300eec23701
- I copied
lc.exe to every project directory and run the following command: lc.exe
/target:Aegon.Xing.Modules.WebAgent.DAL.dll /complist:licenses.licx /i:bin\Debug\Devart.Data.Oracle
/v
- Target is
the name of the assembly which is the project compiled to. In this case this is
a class library project which is compiled to assembly named
Aegon.Xing.Modules.WebAgent.DAL.dll.
- I is the
path to the assembly which is in licx file. I have lc.exe in the project root,
so the relative path to devart assembly is bin\Debug
- Lc creates
a binary file aegon.xing.modules.webagent.dal.dll.licenses. Include this file
to your project and set it as embedded resource. During the compilation the
compiler will find this resource and put it inside Aegon.Xing.Modules.WebAgent.DAL.dll assembly. You can check it with
reflector.
- Repeat with each
assembly which is using devart directly.
- You need
to precompile the licenses only once, once they are attached to projects, the
project could be compiled on machines without devart installed (build etc). I
am afraid after upgrading devart to higher version you need to repeat the
precompilation ...
- The
only thing I’m not sure is with the web application, I played with the
licensing for a week and tried many things which didn’t work, web application
is running by IIS worker process, so on devart forums there is an advice to
create a text file licenses.config ,
put it next to lc.exe and the licx file and put inside the name of the worker
process: w3wp.exe. I did this, my application works, but I think it is not
necessary. (but don’t have energy to try without it, I lose too much time with
playing with licenses..). Why I think it is not necessary is because my
integration test are compiled and run on the build server without installed devart
and they work, and I don’t have the name of the test runner in the .config
file. Which is the same situation as with w3wp.exe.
This is the
end of the story, I hope.
