MSDeploy throwing weird error: Stream data of xxxxx.dll is not yet available
Asked Answered
J

3

7

I am deploying a number of .Net projects to different servers. To do this my team is using TFS to build, then from the build template calling a ps1 script that uses msdeploy to push to all the different servers. It's all very enterprisey and no, I am not at liberty to switch to something different at the moment. This process has been working for months with no issues.

Today the deploy failed a few times in a row with a few different errors. That alone confuses me (and may not be relevant) but now the one I am getting consistently is this:

An error occurred when the request was processed on the remote computer. The stream data of 'C:\Builds\SomeDirectory\obj\Debug\Package\PackageTmp\AReferencedProject.dll' is not yet available.

This error is happening when my script runs msdeploy. The dll is used by a windows service but the service is stopped (as far as I can tell - the service stop isn't throwing any errors) and the dll is not 'read only'. The dll exists on the machine that is building/deploying as well as the machine that is being deployed to.

I have discovered I can avoid this error if I delete the dll that 'is not available' from the server I am deploying to, but the problem comes right back on each subsequent deploy unless I manually delete this dll before each deploy.

I have seen this problem but I am not pushing to Azure, just to Windows Server 2008. Does anyone know why Microsoft web deploy (msdeploy) would throw this error?

Jarrell answered 2/5, 2013 at 20:46 Comment(0)
D
8

I had the same problem. Tried deploying a couple of times with the same error.

Recycling the app pool on the server solved the problem, so that I could run a normal deploy again.

Delphiadelphic answered 20/5, 2013 at 14:54 Comment(3)
I wish I would get this prob again so I could test these proposed solutions :(Jarrell
It has reared its ugly head again, but I tried recycling all the app pools, restarting IIS and even restarting both the build and web servers. None of those helped meJarrell
OK - this solves the problem. My specific problem was that the dll was locked, just like your problem. The only difference was the deploy I inherited was deploying both web sites and services. The services were being deployed in a kind of hacked way using msdeploy, and I found by looking at the build log that it was a service that was having the issue. After looking at the service I found that it was stuck, so I killed it and restarted - pretty much the same thing as restarting the app pool for a siteJarrell
H
3

We are experiencing this problem consistently with SQLite.Interop.dll (used by ELMAH in our web application.) As best I can tell, the problem relates to the fact that the DLL SQLite.Interop.dll is in use by our web app through ELMAH, and for some reason this DLL is not shadow copied. The solution we are using is that recommended here of recycling the app pool upon every deploy. Our command is like:

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:recycleApp -dest:recycleApp="Default Web Site/ourApp",computerName="DeployComputer"

This allows the subsequent msdeploy which syncs our deploy package to succeed. Someone replied to that forum also suggesting using "-enableRule:AppOffline", which we didn't need to try.

Hardecanute answered 13/11, 2013 at 17:34 Comment(0)
F
0

I have been suffering from the exact same issue as you today and having come across your question with no answer, was beginning to pull my hair out...There are just so few articles or suggestions on this issue that I almost gave up!!

However, I have been able to solve the problem for me so I'm posting my solution to help yourself and anyone else who suffers from this issue.

For whatever reason, it seemed that my Site & AppPool in IIS had got a bit muddled up and started to throw the error as described in the question above. To resolve this, I took down the original site (Stopped the Site and AppPool), created a brand new Site and AppPool with the same settings, published to it using WebDeploy and it now seems to be behaving itself again.

This might not work for others, but it will hopefully give people something else to try.

Fissirostral answered 8/5, 2013 at 15:0 Comment(1)
Thanks John. I haven't seen it lately (just disappeared without me doing anything) but I will try this solution if it rears its ugly head again. I wonder if it could have something to do with folder permissions since creating a new site solved it for youJarrell

© 2022 - 2024 — McMap. All rights reserved.