building the source

Jun 8, 2010 at 2:34 PM
Since the implementation of ListDirectoryInGuest swallows all the directories and only returns files, I need to make some modification to the source code. However, the whole solution doesn't really build out of the box. For starters.. is there a document that explains the build environment you need? It seems there are several prerequisites that I haven't found mentioned. It starts with C:\Temp\Vestris.VMWareTasks\1.4\Source\VMWareTasks.proj(2,11): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. Another issue is the check for the Interop.VixCOM.dll dll - it seems to reference the wrong folder (in my case it expects it to be in C:\Temp\Vestris.VMWareTasks\1.4\Source\Source\Interop.VixCOM but that directory doesn't even exist in the source directory). If you get past that, we have a code signing issue Error 1 Cryptographic failure while signing assembly 'C:\Temp\Vestris.VMWareTasks\1.4\Source\Source\VMWareLib\obj\Debug\Vestris.VMWareLib.dll' -- 'Error reading key file 'C:\Users\dblock\Source\CodePlex\vmwaretasks\trunk\master.snk' -- The system cannot find the path specified. ' VMWareLib I finally got that file by downloading the latest source code revision and creating the appropriate folders. I also noted that various projects refer to some .xml/.cd files that aren't present in the 1.4 release source directory.
Coordinator
Jun 8, 2010 at 3:02 PM

I will add a doc on how to build the project. In the meantime here's what you need.

MSBuild Community tasks is used to generate all kinds of stuff that you get errors about and the source drop needs work to be buildable so getting source from svn will fix it.

Send patches for any fixes you make and don't hesitate to ask questions!

Jun 14, 2010 at 8:42 AM
With those instructions, I managed to build without a glitch (after installing VIX on my build box). I've successfully integrated my changes, but I do have one issue: I need to keep the reference to the host system and guest VM across methods. So, when I terminate whatever that I want to do, I try to release the resources by calling close() on both vm reference and host reference. As soon as I call close though, Visual Studio tells me Error 1 The type 'Interop.VixCOM.IVM2' is defined in an assembly that is not referenced. You must add a reference to assembly 'Interop.VixCOM, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1a2e7e25925ba452'. D:\Temp2\Remotesupport\Test Projects\RemoteSupportServer\RemoteSupportServerLib\VMMonitor.cs 477 21 RemoteSupportServerLib So, when I add the explicit reference to my own build Interop.VixCOM, then I get the following error to each call to close() Error 1 Type 'Vestris.VMWareLib.VMWareVirtualHost' from assembly 'c:\Temp\Vestris.VMWareTasks\trunk\VMWareTools\Vestris.VMWareLib.dll' cannot be used across assembly boundaries because a type in its inheritance hierarchy has a generic type parameter that is an embedded interop type. D:\Temp2\Remotesupport\Test Projects\RemoteSupportServer\RemoteSupportServerLib\VMMonitor.cs 371 27 RemoteSupportServerLib Have you ever encountered that and do you maybe know a workaround, or can I safely not call close in my scenario? Also, there aren't too many samples around so I'm wondering - what do you recommend with regards to keeping long term references? My app is controlling virtual machines (start, stop, reset) and will do I/O operations upon request. Should I set up a new connection for each API call, or can I just connect one and keep those references indefinitely? Finally.. are you interested in improvements on the lib? I have added two methods to get a detailed directory listing (returning a List of GuestFileInfo), and I might extend the tools to not only read files but also write files (currently that code is in my own lib because I need to test it first but I figured in the end I could move it to the vmwaretask lib)? If so, I'd gladly submit patches.
Coordinator
Jun 14, 2010 at 11:37 AM

For the first problem, read this article. I think you can easily work around it by never calling a IVM/IVM2 interface yourself and always using the VMWareTasks wrapper. This means closing references via IDisposable for all objects that implement it in VMWareTasks. Use using(VirtualMachine vm = ...) { } construct or calling Dispose() for all disposable objects when you're done with them. Those are almost all VMWareTasks objects that wrap ones in VixCOM, not just virtual machine and host. If you don't dispose everything that's disposable, you will start seeing crashes left and right - VMWareTasks took great care of making it really easy for you :)

There're actually quite a few samples - the unit tests. They cover the entire VMWareTasks API and run against all types of virtual machines. You can configure a VM in App.config in the unit tests and run NUnit on the VMWareLibUnitTests.dll, VMWareToolsUnitTests.dll, etc. If you're building open-source software, post a reply to this thread (you should even if it's not open-source) and mention that the source is available - it will serve as a sample too.

I believe that as long as you need the virtual machine, you can keep a VMWareVirtualMachine object around and use it. I've mostly used VMWareTasks with RemoteInstall and it keeps references for, often, 20-30 minutes. I think VixCOM pools connections anyway.

I am absolutely positively interested in improving the lib!!! Please send patches and don't hesitate to ask fr help. Before you send a patch, remember this:

  • Write unit tests for all new or changed functions.
  • Document functions.
  • Add a line to WhatsNew.html.

If you send something good, I'll give you write access to SVN.

Thx
-dB.

 

 

 

Jun 14, 2010 at 1:21 PM
Edited Jun 14, 2010 at 1:43 PM
As far as calling Dispose() instead of Close(), the issue remains the same, and the using construct remains no option if you want to keep the references around for further use.
When you say crashes left and right.. do you mean crashes in my app, in the lib or on the VMWare Server itself? I'm seeing the latter quite often in my tests but so far I'm not cleaning up after myself and I'm creating new references all the time so that could have something to do with it.
How do you dispose of long term references in RemoteInstall?
Coordinator
Jun 14, 2010 at 1:43 PM

I don't think I understand why you're getting this problem - if you can try to write a short repro, I'd be happy to take a look. Personally I've never seen this error.

RemoteInstall generally uses the using( ... ) construct, which ends up calling IDisposable.Dispose.

Jun 14, 2010 at 3:17 PM
I haven't found a way to upload files here.. so I've uploaded a small sample project to rapidshare:

http://rapidshare.com/files/398958787/VMWareServer.zip.html

The 3 dlls references I took out of the compiled VMWareTools project (build from the latest SVN revision). Remove the reference to the interop DLL and you have the errors with Dispose/Close/Disconnect, add it and you get a whole bunch of other errors.

Coordinator
Jun 15, 2010 at 10:58 AM

This seems to be all .NET Framework 4 related. Two things worked for me:

  • Targeted .NET Framework 3.5 in your application.
  • Changed the option 'Embed Interop Types' to false on Interop.VixCOM. I am not totally sure what this does :)

Let me know if you need anything else.

Aug 6, 2010 at 12:01 PM

I've had to tend to other things for a but... but I have a new colleague who's looking into this now.

Your suggestion does work - but I'm afraid it didn't help with my other problems. If we keep the references around and don't close/dispose, then eventually the .NET app simply disappears without a trace (no errors, no exceptions... the app just dies silently).

If we call close & dispose after each call, then eventually the VM dies.

Now.. what we're doing with the API might be a bit special.. I've written an API based Windows Explorer replacement... and we can cause the issues mentioned above if we start uploading / downloading files to / from the VM - single files work fine, but if you go nuts and move big directories, eventually you run into one of the two problems mentioned above. So far we've never had an issue controlling the VM (check status, start of offline, reboot under certain conditions... but all those are operations that are "slow" compared to what we're doing with the explorer.... so you have a limited number of API calls over a period of time, not dozens or even hundreds of API calls potentially within seconds when you're copying entire directories).

Coordinator
Aug 6, 2010 at 6:18 PM
ssteiner wrote:

I've had to tend to other things for a but... but I have a new colleague who's looking into this now.

Your suggestion does work - but I'm afraid it didn't help with my other problems. If we keep the references around and don't close/dispose, then eventually the .NET app simply disappears without a trace (no errors, no exceptions... the app just dies silently).

If we call close & dispose after each call, then eventually the VM dies.

Now.. what we're doing with the API might be a bit special.. I've written an API based Windows Explorer replacement... and we can cause the issues mentioned above if we start uploading / downloading files to / from the VM - single files work fine, but if you go nuts and move big directories, eventually you run into one of the two problems mentioned above. So far we've never had an issue controlling the VM (check status, start of offline, reboot under certain conditions... but all those are operations that are "slow" compared to what we're doing with the explorer.... so you have a limited number of API calls over a period of time, not dozens or even hundreds of API calls potentially within seconds when you're copying entire directories).

Wha! This sounds like a fun project :) 

I think that maybe you have enough manpower to invest into a native implementation of VMWareTasks that doesn't use COM. That would certainly remove a large chunk of uncertainty from all of this. It would be a straightforward port, implementing everything that calls Interop.VixCOM in VMWareTasks to use PInvoke and call the VIX DLL directly. If someone were to do this, I'd be glad to help a bit and maybe write a Java port with JNA eventually.