Access denied problem for external dll

Question

Hi, all

I have a problem with dll file. I use this dll to execute some actions during build, but can't remove it after using.

This is a part of csproj file, that contains code to build a different project and execute a task:

<UsingTask TaskName="TFSBuildEngine.CreateBranchFiles" AssemblyFile="..\assemblies\SideBySideCreator.dll" />
  <Target Name="BeforeBuild">
    <MSBuild Projects="..\Tools\TFSBuildEngine\TFSBuildEngine.csproj" Targets="Rebuild" Properties="AssemblyName=SideBySideCreator" />
    <CreateBranchFiles SideBySideName="$(DefaultSideBySideName)" />
    <Exec Command="del ..\assemblies\SideBySideCreator.dll" />
  </Target>

If I comment "<CreateBranchFiles SideBySideName="$(DefaultSideBySideName)" />", then all works fine.

Actually, I don't need to remove this dll. It is just an example. It shows, that "SideBySideCreator.dll" is locked by msbuild process. The real problem is working from VS. I can't build this project several times from VS, because "SideBySideCreator.dll" is locked.

I need to unlock this dll somehow after using it, i.e. command "del" should works fine.

Is it possible?

Answer 1

Hi Kong83,

Yes, it is expected.  CreateBranchFile is a custom task which is defined inside SideBySideCreator.dll. The msbuild will load the DLL once executing the CreateBranchFile. Generally speaking, the instance of MSBuild (MSBuild Process) will release all loaded DLL when it is finish. Therefore we can't delete the dll during the building process, it is in use.

For your real problem, "I can't build this project several times from VS, because "SideBySideCreator.dll" is locked.",  we need more information to check why it is locked, do you need to modify or delete the dll file during run time? if so, it may be the root cause. Please aviod such actions for the custom task assembly.

If I misunderstand you, please let me know.

Regards,

Yi

---

Yi Feng Li [MSFT]
MSDN Community Support | Feedback to us

Answer 2

Hi Yi Feng Li

Thanks for your answert. I have understood your explanation, but it is strange, why VS doen't release dll after each build (but after closing VS only).

For example, if I run a build of solution from the command line, I can remove the dll after build finish. But if I open solution from VS and run build, I can't remove the dll until I close VS, because the dll is locked by denenv.exe process.

It is a bad design of VS, isn't it?

Answer 3

Hi Kong,

Is there any samples or repro step you can show us to repro this issue? Without a repro, it is hard for us to determine the exactly root cause.

Regards,

Yi 

---

Yi Feng Li [MSFT]
MSDN Community Support | Feedback to us

Answer 4

I have created a sample for you.

If you open it in VS 2010, the second build will be failed.

If you use the command line, no errors occur.

Try to download it:

TestApplication

If you can't download, write me to   k o n g 8 3 @ q i p . r u  and I will send you this test application by email.

Answer 5

Hi Kong,

Thank you for your sample. I'm looking into it and update the thread asap.

Yi

---

Yi Feng Li [MSFT]
MSDN Community Support | Feedback to us

Answer 6

Hi Kong,

Your DLL is a custom task assembly, once the Visual Studio process launch the task dll, it will not release the dll until the Visual studio be terminated. However, the task DLL is a part of solution, it will also need to rebuild sometime but it is locked by the VS.

I don't think this an ideal way to invoke the custom task for your solution, since it will be come a dead lock loop for the end. I suggest you put the custom task dll outside the solution to make sure there is no dead lock.

Regards,

Yi

---

Yi Feng Li [MSFT]
MSDN Community Support | Feedback to us

Answer 7

Hi Yi Feng Li

>>I suggest you put the custom task dll outside the solution to make sure there is no dead lock.

I had to do such way :)

I just thought, that a tricky action exists to unlock my dll during the build process...

Anyway thanks for your help and participation.

Answer 8

Hi Kong

Based on my knowledge, a .Net assembly is loaded into the memory, either by default reference or loaded by runtime using Assembly namespace, there is no way to release it before the process terminated or close the app domain.

But for native DLL you can do that, load and release it in runtime. Therefore a way you may consider, write a managed Task DLL as a host to runtime load the native task DLL and free it after. The main logic is written in the native C++ one in your solution. The host Task DLL is an assembly only which is not created in your current solution, it will never required to rebuit.

I didn't tested such idea but you may have a try.

Regards,

Yi 

 

---

Yi Feng Li [MSFT]
MSDN Community Support | Feedback to us

Answer 9

Hi,

I am writing to check the status of the issue on your side.  Would you mind letting us know the result of the suggestions? 

Yi

---

Yi Feng Li [MSFT]
MSDN Community Support | Feedback to us

Answer 10

Hi Yi Feng Li.

The native dll is bad way for us. We don't use native code. We decided to use a ready dll instead of building it during the all build process.

I think, you can close this thread. Thanks for your help.

Answer 11

Hi Kong,

Thank you for your update. I will close the thread by mark my reply and your workaround post as answer.

Regards,

Yi

---

Yi Feng Li [MSFT]
MSDN Community Support | Feedback to us