none
Can I see what how Visual Studio is calling cspack?

    Question

  • Is there anyway I can see the exact call visual studio is making to cspack when I do a "publish"?

    When I deploy through a visual studio "publish" everything works fine; but when I deploy the same project through a tfs build, I get the role recycles (initializing, stop, etc...).

    I created my own cspack call, but I'd like to see what visual studio is doing - the "copy local=true' properties probably have an impact on the cspack call.  

    Here's what I have now - 

    "c:\Program Files\Windows Azure SDK\v1.2\bin\cspack.exe" "C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20100924.3\Release\MYPROJECT.Deploy.csx\ServiceDefinition.csdef" /role:MYPROJECT.MYWEBROLE1;"C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20100924.3\Release\MYPROJECT.Deploy.csx\roles\MYPROJECT.MYWEBROLE1\approot";MYPROJECT.MYWEBROLE1.dll /role:MYPROJECT.MYWORKERROLE1;"C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20100924.3\Release\MYPROJECT.Deploy.csx\roles\MYPROJECT.MYWORKERROLE1\approot";MYPROJECT.MYWORKERROLE1.dll /out:"C:\Builds\StealthLab.Packages\MYPROJECT.Development\MYPROJECT.Deploy.cspkg"


    Wednesday, October 06, 2010 11:43 PM

Answers

  • Is it a .NET 4 app?  If so, be sure to set TargetFrameworkVersion=v4.0 in a specified file via the /rolePropertiesFile cspack parameter.
    • Edited by Steve Marx Thursday, October 07, 2010 12:48 AM
    • Marked as answer by Emmanuel Huna Thursday, October 07, 2010 7:23 PM
    Thursday, October 07, 2010 12:47 AM
  • Steve, that did it, thank you!  For others here are the details:

    1) Create a text file, I called it "cspackproperties.txt" and placed it in the same directory where my Azure project is located (where my .csdef and .cscfg files are also located).

    2) In this cspackproperties.txt file, add one line:

      TargetFrameWorkVersion=v4.0

     

    3) When calling cspack, for each role pass in the parameter /rolePropertiesFile - so my call to cspack became:

    "c:\Program Files\Windows Azure SDK\v1.2\bin\cspack.exe" "C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20101007.1\Release\MYPROJECT.Deploy.csx\ServiceDefinition.csdef" /role:MYPROJECT.MYWEBROLE1;"C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20101007.1\Release\MYPROJECT.Deploy.csx\roles\MYPROJECT.MYWEBROLE1\approot";MYPROJECT.MYWEBROLE1.dll  /rolePropertiesFile:MYPROJECT.MYWEBROLE1;"C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20101007.1\Release\MYPROJECT.Deploy.csx\cspackproperties.txt" /role:MYPROJECT.MYWORKERROLE1;"C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20101007.1\Release\MYPROJECT.Deploy.csx\roles\MYPROJECT.MYWORKERROLE1\approot";MYPROJECT.MYWORKERROLE1.dll /rolePropertiesFile:MYPROJECT.MYWORKERROLE1;"C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20101007.1\Release\MYPROJECT.Deploy.csx\cspackproperties.txt" /out:"C:\Builds\StealthLab.Packages\MYPROJECT.Development\MYPROJECT.Deploy.cspkg"

    Inside Baseball

    Steve: is this simply creating the RoleModel.xml file correctly?  

    Before you gave me the above tip, I set the environment variable _CSPACK_FORCE_NOENCRYPT to true so Visual Studio would not encrypt the package and I also passed in the /noencrypt parameter to cspack. Using winmerge (http://winmerge.org/) – I had just found out:

    1) There were no issues of dependent 3rd party dlls – they were present in both packages.
    2) The main difference seemed to be the “RoleModel.xml” file, which was empty on the tfs build version.


     

    • Marked as answer by Emmanuel Huna Thursday, October 07, 2010 7:23 PM
    Thursday, October 07, 2010 7:23 PM

All replies

  • Is it a .NET 4 app?  If so, be sure to set TargetFrameworkVersion=v4.0 in a specified file via the /rolePropertiesFile cspack parameter.
    • Edited by Steve Marx Thursday, October 07, 2010 12:48 AM
    • Marked as answer by Emmanuel Huna Thursday, October 07, 2010 7:23 PM
    Thursday, October 07, 2010 12:47 AM
  • P.S. This week's Cloud Cover episode (http://channel9.msdn.com/shows/Cloud+Cover) will demonstrate this.
    Thursday, October 07, 2010 12:47 AM
  • Hey Steve - thanks I'll try it out and I'll update this thread with details.  I'll definitely watch this week's Cloud Cover - anyone working with Windows Azure should!

    From the original question - is there a way to see the exact cspack call Visual Studio is making?  This way in the future, I may be able to see such parameters directly.

    Now I'm on to some tasty desert pizza. ;-)

    Thursday, October 07, 2010 5:52 PM
  • Steve, that did it, thank you!  For others here are the details:

    1) Create a text file, I called it "cspackproperties.txt" and placed it in the same directory where my Azure project is located (where my .csdef and .cscfg files are also located).

    2) In this cspackproperties.txt file, add one line:

      TargetFrameWorkVersion=v4.0

     

    3) When calling cspack, for each role pass in the parameter /rolePropertiesFile - so my call to cspack became:

    "c:\Program Files\Windows Azure SDK\v1.2\bin\cspack.exe" "C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20101007.1\Release\MYPROJECT.Deploy.csx\ServiceDefinition.csdef" /role:MYPROJECT.MYWEBROLE1;"C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20101007.1\Release\MYPROJECT.Deploy.csx\roles\MYPROJECT.MYWEBROLE1\approot";MYPROJECT.MYWEBROLE1.dll  /rolePropertiesFile:MYPROJECT.MYWEBROLE1;"C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20101007.1\Release\MYPROJECT.Deploy.csx\cspackproperties.txt" /role:MYPROJECT.MYWORKERROLE1;"C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20101007.1\Release\MYPROJECT.Deploy.csx\roles\MYPROJECT.MYWORKERROLE1\approot";MYPROJECT.MYWORKERROLE1.dll /rolePropertiesFile:MYPROJECT.MYWORKERROLE1;"C:\Builds\MYPROJECT.Development\MYPROJECT.Development_20101007.1\Release\MYPROJECT.Deploy.csx\cspackproperties.txt" /out:"C:\Builds\StealthLab.Packages\MYPROJECT.Development\MYPROJECT.Deploy.cspkg"

    Inside Baseball

    Steve: is this simply creating the RoleModel.xml file correctly?  

    Before you gave me the above tip, I set the environment variable _CSPACK_FORCE_NOENCRYPT to true so Visual Studio would not encrypt the package and I also passed in the /noencrypt parameter to cspack. Using winmerge (http://winmerge.org/) – I had just found out:

    1) There were no issues of dependent 3rd party dlls – they were present in both packages.
    2) The main difference seemed to be the “RoleModel.xml” file, which was empty on the tfs build version.


     

    • Marked as answer by Emmanuel Huna Thursday, October 07, 2010 7:23 PM
    Thursday, October 07, 2010 7:23 PM
  • I actually don't know where that target framework version setting ends up... what you did is a great way to see the impact.  At this point you know more than I do. :-)
    Thursday, October 07, 2010 10:44 PM