Activity dll is locked after import

Sep 14, 2010 at 11:44 PM

Hi, there

We have found this problem long time ago, but now it is becoming a stuck problem.

When we compile again after we import an activity into Trident,  it prompts "The target dll is being used, cannot be overwritten". 

We have to close the Trident, then we can compile again.

After we review your codes, we found this line: "helper.ImportActivities(references, true)", and also we knew if we load an assmebly directly, this assembly is locked somewhere, even we have completed the process

 For example:

 if we call    Assembly o = Assembly.Load(file);  the file is actually is locked after the process.

Unless, we use the following code, load an assembly from an array of bytes.

 byte[] buffer;
                        using(FileStream fileStream = new FileStream(uniqueFilename, FileMode.Open, FileAccess.Read))
                            int length = (int)fileStream.Length;  // get file length
                            buffer = new byte[length];            // create buffer
                            int count;                            // actual number of bytes read
                            int sum = 0;                          // total number of bytes read

                            // read until Read method returns 0 (end of the stream has been reached)
                            while ((count = fileStream.Read(buffer, sum, length - sum)) > 0)
                                sum += count;  // sum is a buffer offset for next reading
      Assembly o = Assembly.Load(buffer);

Is it possible for you to load the acitvity dll from bytes rather the file directly? or you have an alternative?







Sep 15, 2010 at 1:08 PM


Thank you for showing interest in Trident.

We are looking into your concern. We will keep you posted on the updates.

Please let usnow if you have any questions.
Trident Support Team

Sep 16, 2010 at 5:38 PM


As far as loading of assemblies is concerned, we have two ways of loading assemblies making sure than once the operation is done we can unload the assemblies:

1. Using the AppDomain approach :

In this approach we create a new AppDomain for loading assemblies and then load the assembly in the newly created AppDomain. Then once all the operations are carried out for that appdomain we safely unload the appdomain.

By following this approach we take care of two thing. First, we will lock the assembly file only till it is required; Second, we will not overload the base application with more assemblies.

2. Load the file into memory first, using the byte[] buffer approach : We load the assembly to a file, rather than loading the assembly to the memory. This way there is no direct connection of the assembly in the memory. This is done by creating reading the assembly from a FileStream and loading it on a byte[] buffer. Instead of loading the assembly to the memory we load the buffer. This prevents the assembly from getting locked.

We would recommend AppDomain approach because:

  1. A new AppDomain is created which loads the assemblies, thus not interfering with the existing main AppDomain.
  2. Frees all the resources once the AppDomain is unloaded.
  3. It increases isolation, stability, and security of our application.

Considering Trident, We have followed AppDomain approach.

Where we create a new appdomain, whenever we are importing activities/workflow/Packages. Once the import is done we safely unload the appdomain and thus the assemblies are unloaded.

Related to the issue which you have mentioned, we need to check what is exactly causing the problem. As a guess we could say that the problem might be in unloading the appdomain.

Please let us know if this solves your concern.
Trident Support Team.

Sep 20, 2010 at 6:34 AM


Can you please let us know if the answer solves your concern?

Trident Support Team

Sep 24, 2010 at 12:08 AM

Many thanks.

We are expecting your check


Oct 4, 2010 at 10:45 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.