locked
Strange Error on Build (DSSProxy) RRS feed

  • Question

  • Normally I get this error when I forget that I have a node running in the background and try to compile anyways, but this is the first time I've gotten it with no nodes open. I restarted to make sure nothing was running accidentally. Any suggestions?

     

    Code Snippet
    Error 1 Unable to copy file "obj\Debug\CategoryAgent.Y2007.M07.Proxy.dll" to "C:\Microsoft Robotics Studio (1.5)\bin\CategoryAgent.Y2007.M07.Proxy.dll". The process cannot access the file 'C:\Microsoft Robotics Studio (1.5)\bin\CategoryAgent.Y2007.M07.Proxy.dll' because it is being used by another process. C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets 2314 9 CategoryAgent

     

     


     

    Friday, July 20, 2007 4:40 PM

Answers

  • It is just the one service. It's not a CE project, and there's only one line in the post-build events. I tried removing it and it compiled fine. It failed when I put the line back in.
    Tuesday, July 24, 2007 10:47 PM

All replies

  • Please check which process is holding the file open. You can for example use the handle tool [1].

     

    [1] http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/Handle.mspx

    Friday, July 20, 2007 5:04 PM
  • I ran the handle tool when I wasn't trying to compile, and nothing was using the dll. When I was trying to compile there were two processes that came up, one was DssProxy and the other was reported as <Non-existent Process>, but they shared the same PID. One reported using the DLL as a DLL, the other was a Handle. I don't really know what this means, so let me know if I'm leaving some information out.
    Friday, July 20, 2007 5:12 PM
  • sometimes VS keeps handles open due to the debugger process. consider restarting VS. Also make sure no dss node is running at the time of compile
    Saturday, July 21, 2007 4:21 AM
  • I've restarted VS and restarted Windows, making sure that the first app I ran was VS to compile the service. Still no luck...
    Monday, July 23, 2007 6:06 PM
  • Hmm, does it make any difference if you compile from the MSRS command line using msbuild, for example? 

    Code Snippet
    msbuild service.csproj

     

    it would be good to know whether VS has anything to do with it.

     

    Henrik

    Monday, July 23, 2007 7:56 PM
  • Henrik,

    I tried using msbuild at the command line and I got the same errors. I'm totally stumped.

    Josh
    Monday, July 23, 2007 9:11 PM
  • Ok, so it is not VS then.

     

    From your explanation, it seems that this is new; that is, you have compiled successfully in the past with the 1.5 installation, right? If so, did something on your system such as a virus scanner or something else that could touch the file system change?

     

    Does it only happen with dssproxy? Not when compiling the service itself?

     

    Only other thing I can think of is to try procmon [1] which can monitor file system access in real time. it works best if you only set it to monitor the filesystem and add a filter for the path under the MSRS installation. It should tell you who accesses all files and how.

     

    Henrik

     

    [1] http://www.microsoft.com/technet/sysinternals/FileAndDisk/processmonitor.mspx

    Tuesday, July 24, 2007 7:57 PM
  • If you haven't tried the following, I'd be interested to know if it solves your problem.

     

    1. Reboot the computer

    2. Do not start any MSRS services or applications.  Do not open Visual Studio.

    3. Open the Microsoft Robotics Studio Command Prompt

    4. Compile your project using msbuild from inside the command prompt.

    Tuesday, July 24, 2007 8:12 PM
  • Henrik,

    This is a new error, I am using 1.5, and it did work in the past. I do not think I changed anything on my system.

    As far as I can tell it only happens with dssproxy. Is there a way to compile without generating the proxy to check?

    I downloaded procmon and followed your instructions. When I compile the proxy.dll is accessed by VCSExpress.exe DSSProxy.exe csc.exe and then DSSProxy.exe again, in that order.
    Tuesday, July 24, 2007 8:39 PM
  • Dave,

    I tried this, and got exactly the same error.
    Tuesday, July 24, 2007 8:45 PM
  • Hi Josh.  Sorry you are having these issues.

    I have a few more thoughts -- I'm sorry if you've already tried these things.  I'm just trying to be thorough.

     

    Are you running Vista?

    Do you normally open VS and the command prompt as an administrator? 

     

    If you are running Vista, try opening VS and/or the MSRS command prompt as an administrator.  In Vista, even if your account is in the Administrators group, by default you are not running with Administrative privs.  You need to right click on your program icons and choose "Run as administrator".

     

    Perhaps the permissions in "C:\Microsoft Robotics Studio (1.5)\bin\" are preventing the file from being copied.

     

    Can you manually delete the two files in question?  The first file is relative to your project directory.

    • ...\obj\Debug\CategoryAgent.Y2007.M07.Proxy.dll
    • C:\Microsoft Robotics Studio (1.5)\bin\CategoryAgent.Y2007.M07.Proxy.dll

     

     

    Tuesday, July 24, 2007 8:55 PM
  • Thanks for your help Dave.

    I am running Vista, and tried running VS as an admin, but that didn't help.

    However, when I deleted the file in \bin, the service would compile once. Then when I tried a second time it failed. Also, when the service compiled the first time, it failed to actually start-up in the dssnode.
    Tuesday, July 24, 2007 9:33 PM
  • Posted By:   Josh de Leeuw on 07-24-2007 8:39 PM UTC

    Subject:   Re: Strange Error on Build (DSSProxy)

    Message:

    Henrik,

    This is a new error, I am using 1.5, and it did work in the past. I do not think I changed anything on my system.

    As far as I can tell it only happens with dssproxy. Is there a way to compile without generating the proxy to check?

    I downloaded procmon and followed your instructions. When I compile the proxy.dll is accessed by VCSExpress.exe DSSProxy.exe csc.exe and then DSSProxy.exe again, in that order

     

    Is this just happening with one service, or with all of your services?

     

    By any chance are you working with a CE project? 

    I would expect DssProxy to only be called once during the compilation... unless you are working on a CE project.

     

    If this is an x86 project, are there two lines in your post-build event?  The proxy generation happens in the <PostBuildEvent> in your csproj file. 

    You can view the properties in VS under Build Events, or edit the *.csproj file manually.

    Try removing the call to DssProxy (save a copy so you can put it back). 

    Tuesday, July 24, 2007 9:58 PM
  • It is just the one service. It's not a CE project, and there's only one line in the post-build events. I tried removing it and it compiled fine. It failed when I put the line back in.
    Tuesday, July 24, 2007 10:47 PM
  • Can you send the dssproxy line that is embedded in your csproj file?

     

    Also, you might try using DssNewService to generate another project (in a different folder, but with the same name).

    Compile it immediately to make sure you don't have the same issue, then copy your *.cs files into that directory and add any new ones to the project, add any additional references, then see if this takes care of the problem.

     

    David

     

     

     

    Thursday, July 26, 2007 11:28 PM
  • I had all the same symptoms and tried all the things suggested in this thread. Finally I found out that placing the [DataMember] attribute in the state class wrong causses this <irony>logical error message</irony>.

    The code that didn't work looked like this

            [DataMember]
            string version;
            public string Version
            {
                get { return ""; }
                set { }
            }

    when it really should be like this

            string version;
            [DataMember]
            public string Version
            {
                get { return ""; }
                set { }
            }


    Well I can't really blame anybody but my self for this obvious mistake but the error message wasn't really useful for anything but entering into google.
    Thursday, September 6, 2007 9:45 AM