I have a workflow service activity which is showing some strange behaviour. The first issue is that if the workflow is open in the designer and I perform a full rebuild then I get a compiler message saying
warning MSB3061: Unable to delete file "E:\Work\etc.\MyAssembly.dll". Access to the path 'E:\Work\etc.\MyAssembly.dll' is denied.
If I check what is keeping a handle to the file it is indeed devene.exe. If I close the designer then I can perform a rebuild. The second unusual thing I am seeing is that the custom activities (which are in a seperate assembly) are not being recognised, again just by the designer. So if I attempt to build it tells me it 'Could not find type "MyType" in assembly "MyOtherAssembly"'. If I open the activity is code view (i.e. XML view) then it builds fine and recognises all my types (as it should as I they are referenced correctly). Also, there activies used to show up in the workflow toolbox, but no longer do so.
I should note that the issue is not just with the particular workflow I am working on. If I delete this workflow and add another service workflow I see the same behaviour, so the issue is with the project itself somehow. I have tried creating a new project from scratch and adding a service workflow and this seems to work, but I am keen to fix the issue with my current project as it is quite large. Also, I compared the assembly references in the working test project with the one that is not working and everything that is in the working poject is also in the non-working project.
If its relevant the project was not created as a "WCF Workflow Service Application"...the workflow service was something I added after the fact (but when I last opened the designer some months ago the designer was working fine, as did the service).
[UPDATE] After trying all the suggestions and finding that none of them made any difference, I finally took the plunge and stated removing pieces of my project to see what could be causing this issue. The results have turned out to be really really odd, so hopefully someone could assist now that I have narrowed down the issue.
By removing project refernces I narrowed down the problem to one project that my WF project was referenceing. If I referenced this project and opened the WF designed the WF project would not build. The project "causing" the problem was a simple data transfer object library, with no static construtors or anything like that that could cause the WF designer to create/hold onto references. I removed all classes from this DTO project and the problem went away. I then stated adding back the classes and trying to rebuild. Eventually I hit a point where it stops building, but it seems somewhat random. I add back a file and it stops building, remove that file and it works again. I start removing properties from that file (they are all simple value types, ints and strings mostly) and the project doesn't build again until all the properties are gone. If I add any property to the file it stops the build from working. e.g.
public class TestUser
{
public int test {get; set;}
}
The build fails with the above class, however it works with the following class
public class TestUser
{
private int test = 0
}
Totally weird!. So then the next thing I did was add the offending project to a brand new WF service project and initially I don't see the same behaviour. However as soon as I set the solution to build using x64 then the problem appears in the new solution. Therefore the problem only happens on x64 builds, with a certain combination of files from my DTO project. However the exact files seems to be somewhat random...I can add a new class as above and it fails. However if I remove all other classes from my DTO app it works again. Adding them back one by one and it fails again eventually, but not if I remove the class above (i.e. the class that was the problem is no longer the problem).
Bottom line is that this appears to be a bug in the WF4 designer with a service workflow when the build is set to be x64. I need to experiment more to figure out the exact combination of circumstances that is causing the problem, but any ideas welcome in the meantime!.
I eventually found the answer to this question. Basically the WF designer will not work if the solution is setup to compile as 64x. The reason is visual studio itself is a 32bit app and so is unable to load the required assemblies and find any of the types.