Msbuild Python project fail from command line, but build from VS UI succeed

[lezi226]

Hi, I have a very simple Python project, which can be built succeed in Visual Studio UI. But if I build using command line "msbuild.exe CloudServiceWebRole.pyproj", it fail with below error: Do you know the reason? Thanks

...
D:\...\Python Tools\Microsoft.PythonTools.Web.targets(235,5): error MSB4018:
The "ResolveEnvironment" task failed unexpectedly.
System.ComponentModel.Composition.CompositionException: The composition produced
a single composition error. The root cause is provided below. Review the
CompositionException.Errors property for more detailed information.

1) Could not load file or assembly 'Microsoft.VisualStudio.Settings.12.0,
Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of
its dependencies. The system cannot find the file specified.
...

[zooba]

Yes, we currently depend on being able to resolve some VS settings during build, which does not work when we are run outside of VS. We need to add an alternative approach to handle building in this case.

[lezi226]

Thanks for the quick reply, zooba. Is there any workaround for now? I'm asking since I want to use TFS build from visualstudio.com, which only support command line msbuild.

[zooba]

Not without seriously hacking at the version of Microsoft.PythonTools.Web.targets that is on TFS build, unfortunately :( We should have had a property in there to let you bypass environment detection, but we don't. (TBH, I'm not even sure what version of PTVS they're using right now. We are going to be working with them to improve the Python situation very soon, and this is probably our first step.)

[lezi226]

I can setup a private TFS build controller right now. So I should be able to modify the file in the private build controller. Is it possible that you share me a private version, so I can try first?

[zooba]

Actually, there is a way you should be able to do it from your .pyproj file (not our actual targets file).

If you add the following code right at the end (between the <Import> and </Project> elements) and fill in the paths to the location of your Python installation (and optionally change the version numbers) on the build machine then it should be fine:

<Choose>
  <When Condition="$(BuildingInVisualStudio) != 'true'">
    <Target Name="ResolvePythonInterpreterPath">
        <PropertyGroup>
            <VirtualEnvEnabled>false</VirtualEnvEnabled>
            <PythonMajorVersion>3</PythonMajorVersion>
            <PythonMinorVersion>4</PythonMinorVersion>
            <PythonInterpreterPath>C:\Python34\python.exe</PythonInterpreterPath>
            <PythonPathEnvironmentVariable>PYTHONPATH</PythonPathEnvironmentVariable>
            <PythonArchitecture>x86</PythonArchitecture>

            <PythonVersion>$(PythonMajorVersion).$(PythonMinorVersion)</PythonVersion>
            <PythonInterpreterDescription>Python $(PythonVersion)</PythonInterpreterDescription>
        </PropertyGroup>
    </Target>
  </When>
</Choose>

The target name is important, since it has to replace our existing one by that name to avoid trying to load the task. I took a slight guess at the condition in the When element - you may need to tweak it depending on how the TFS build machine sets its properties.

I'll be interested to hear how well this works, as it's a pretty good workaround in general, and it will help us develop a good solution for the general problem.

[lezi226]

After changing the project file with your suggestion, the project can't be loaded by VS anymore. It's the error message I get:

The element < Target > beneath element < When > is unrecognized. d:\Builds\67163\CloudServiceWebRole\CloudServiceWebRole.pyproj

[int19h]

Try doing this instead:

<Target Name="ResolvePythonInterpreterPath" Condition="$(BuildingInVisualStudio) != 'true'">
        <PropertyGroup>
            <VirtualEnvEnabled>false</VirtualEnvEnabled>
            <PythonMajorVersion>3</PythonMajorVersion>
            <PythonMinorVersion>4</PythonMinorVersion>
            <PythonInterpreterPath>C:\Python34\python.exe</PythonInterpreterPath>
            <PythonPathEnvironmentVariable>PYTHONPATH</PythonPathEnvironmentVariable>
            <PythonArchitecture>x86</PythonArchitecture>

            <PythonVersion>$(PythonMajorVersion).$(PythonMinorVersion)</PythonVersion>
            <PythonInterpreterDescription>Python $(PythonVersion)</PythonInterpreterDescription>
        </PropertyGroup>
    </Target>

[zooba]

That will break regular builds, since we always override the existing target and then conditionally execute it. We really need to have both approaches built into the actual target.

Of course, if you don't need to build locally (or you can rely on the same fixed paths) then the approach without Choose and When will be fine.

[lezi226]

Hi, Thanks for these info. I finally got why i hit this build issue, by default "MSBuild platform" parameter in TFS Build Definition is set as "Auto", which invoke amd64 msbuild.exe in the build machine and caused the issue. I changed it to X86, then .pyproj build succeed.

Now the problem becomes cloud service build fail, "msbuild ApiCloudService.ccproj", it's the detail error below:

Target "VerifyRoleReferences: (TargetId:142)" in file "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Windows Azure Tools\2.5\Microsoft.WindowsAzure.targets" from project "c:\test\ApiCloudService.ccproj" (target "CorePackageComputeService" depends on it): Using "WATMessage" task from assembly "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Windows Azure Tools\2.5\Microsoft.VisualStudio.WindowsAzure.Tasks.2.5.dll". Task "WATMessage" (TaskId:87) Task Parameter:Type=Error (TaskId:87) Task Parameter:Arguments=c:\test\ApiServiceWebRole\ApiServiceWebRole.exe (TaskId:87) Task Parameter:Code=WAT070 (TaskId:87) C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Windows Azure Tools\2.5\Microsoft.WindowsAzure.targets(1275,5): error : WAT070 : The referenced assembly c:\testApiServiceWebRole\ApiServiceWebRole.exe was not found. Please make sure to build the role project that produces this assembly before building this Microsoft Azure Cloud Service Project. [c:\test\ApiCloudService.ccproj] Done executing task "WATMessage" -- FAILED. (TaskId:87)

Build in VS UI pass, and the detail log for this particular Target is:

Target "VerifyRoleReferences" in file "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Windows Azure Tools\2.5\Microsoft.WindowsAzure.targets" from project "C:\test\ApiCloudService.ccproj" (target "CorePackageComputeService" depends on it): Task "WATMessage" skipped, due to false condition; ( !Exists('%(_ResolvedProjectReferencePaths.Identity)')) was evaluated as ( !Exists('C:\test\ApiServiceWebRole\bin\Microsoft.PythonTools.WebRole.dll')).

You can see build variable _ResolvedProjectReferencePaths is different between command line msbuild and VS UI build. Do you have any idea please?

[lezi226]

Any idea? thanks

[zooba]

Are you seeing these results locally or on the build machine?

We don't actually control the _ResolvedProjectReferencePaths variable at all, but if one of our targets is failing then the Azure Tools (who do own that variable) may be getting incorrect information.

Can you post the full logs on https://gist.github.com/ and link them? MSBuild related stuff is really hard to figure out without the entire trace.

[lezi226]

Hi, zooba, please check

VS build success https://gist.github.com/lezi226/3ded65fd82a34dc1acb3

cmd msbuild fail https://gist.github.com/lezi226/6f433cfbe3fee101ed57

[lezi226]

any idea please? Thanks

[lezi226]

Hi, any update on this issue? It blocked us for a long time already. Without the fix, we can't do any automotive daily build. Thanks

[zooba]

Sorry we're taking so long on this. There have been a lot of distractions for us :(

I don't have any update. Cloud Service projects are not very well designed for extensibility, which is why they assume that everyone is a .NET application. Apparently we aren't correctly pretending to be a .NET application outside of VS, but I haven't yet been able to figure out how we should handle that situation.

Right now we have another issue that prevents adding Python roles to a cloud service project at all, which is currently taking my attention. Once I get that resolved, I'll be able to make a project to test this issue.

[lezi226]

Ok, thanks for the info. I'll wait for your update.

[divyaspec]

Hi, I am having the similar issue with Python (Flask) project using GIT-VSO preview, MSBuild fails with exit code 1. Python project builds success on visual studio 2013 (Azure VM), however when I push my changes to GIT this automatically starts my build in a queue on VSO preview. I don't know how I can go about fixing this failed build. I am reading this thread and wondered if the issue is solved or can anyone please suggest me further. Thank you.

[zooba]

You should be able to customize the build config in VSO preview to handle this better, but there may be a reason you can't do this right now.

Currently we have had some discussions with getting proper Python support into VSO's hosted builds, but it's stalled as a lot of changes are going on with various products we need to add support for. Once things settle down a bit and we know which ones to work with (we literally cannot afford to add 100% support for the current 8-10 combinations of project/build host/versions that exist now) we'll be able to make things work better. Until then, you're best to avoid building the project directly on hosted services - I believe VSO preview has tasks for packaging and publishing using PowerShell, which should be basically equivalent.

[ckaiman]

I find the same error when trying to do a continuous build from VSO to Azure during the compilation phase of the deployment process. Honestly, as much as I want to showcase Azure for a demo, I might have to use Heroku. Maybe that statement can provide some added ammo to bring to Azure management? I'm guessing they don't want to lose business to Heroku, Amazon, Google, etc. Support for open source matters...

[zooba]

I agree, and we are working on it, but nothing happens instantly. This one in particular requires us (as outsiders, effectively) to coordinate at least two other teams and convince them that there is value in making their existing platforms more flexible. While it may seem like "just writing code" is the solution, we can't actually just dive into their codebase and do it.

VSO Build preview is going to be able to better support non-.NET projects, and explicit support for Python projects will come eventually but is already available through command-line options. Getting Cloud Service projects changed to work better is more difficult (I don't even have a good contact for that team right now). Our own team also has conflicted priorities, and right now we've got everyone focusing on fixing crashes and issues that affect most of our users - working around Cloud Service's lack of extensibility is one of the (many) things that gets pushed down the list.

So yes, we'd love for you to showcase Azure in a demo, but we don't really need more ammo. What we need is to separate the task from the tools, so that everything can be done without Visual Studio, and then we'll break all of these dependencies that creep in and cause trouble (note that that's an ideal situation - it won't happen overnight :) ).

[ckaiman]

It really is too bad that it isn't ready for prime time. Can you point me to a good link for publishing a django app to Azure through the command-line? I have looked but can't find anything that works in practice.

[zooba]

I don't know of any off the top of my head, but @huguesv might.

Git deployment is the best experience for simple Azure Web Apps, but Cloud Service doesn't have any decent equivalent as far as I know. There are certainly Powershell commands for deploying, but bypassing the MSBuild issues requires more hackery (which unfortunately has not been figured out yet).

[huguesv]

For deployment via PowerShell, I found this, which looks correct AFAIK. http://www.kenneth-truyers.net/2014/02/06/deploying-cloud-services-to-azure-with-powershell/ You can also use the Python Azure SDK to deploy, but that's not as well documented. This is what this test does: https://github.com/Azure/azure-sdk-for-python/blob/master/tests/test_servicemanagementservice.py#L940 Both of these assume that you are able to create the .cspkg, as that's the file you have to upload to blob storage.

[divyaspec]

Hi, the above blog was very useful, however what I found in going through the first step (to create a package file - using MSBuild) exec doesn't work. I used Start process in powershell that looks like it should create the package file. But I still can't figure out where this packaged python files(including .config file) are dropped. It obviously didn't drop in my project dir. Has anyone, packaged python project in visual studio using powershell if so, is it called (.pypkg or .cspkg)? .cspkg is C# based project pakcage file if I am not wrong? I am really stuck here, any support will be helpful.

Start-Process .\msbuild.exe –argument list 
                               "/p:Configuration=Release/p:DebugType=None
                                /p:Platform=AnyCpu
                                /p:OutputPath= 
                                /p:TargetProfile=Cloud
                                /t:publish
                                /verbosity:quiet" 

[zooba]

It will be a .cspkg, which I believe is "Cloud Service PacKaGe" (though it could be C# package, given how non-extensible the Cloud Service support is). It's really just a zip file, so you can extract it and see the contents - it will have more zip files inside (one for each web/worker role) that will contain your Python files.

[myetginbal]

Hi, Is there any update on this issue?

[zooba]

Afraid not, we have had more pressing issues to deal with (such as not being able to start VS at all...).

[myetginbal]

Thank you for the update, hope you'll do fine with those issues.

[thelordzero]

Just to add on to this, I'm having the same issue with continuous deployments and builds when pushing from a VSTS hosted GIT repository via VS2015 going onto Azure Web Apps.

[chrisesworthy]

Thank you for your work on this issue. Is there an ETA or relative priority on this fix?

I know you have alot on your plate. Appreciate the work.

[zooba]

Hoping to have this fixed in PTVS 3.0, but we don't have any schedule to announce for that yet.

FWIW, this PEP is what will enable us to fix the issue. Once implemented, we will be able to remove the dependency on VS configuration that prevents us working outside of VS.

[chrisesworthy]

Thanks Steve

From: Steve Dower [mailto:notifications@github.com] Sent: February 24, 2016 4:57 PM To: Microsoft/PTVS PTVS@noreply.github.com Cc: Chris Esworthy Chris.Esworthy@hawcpa.com Subject: Re: [PTVS] Msbuild Python project fail from command line, but build from VS UI succeed (#128)

Hoping to have this fixed in PTVS 3.0, but we don't have any schedule to announce for that yet.

FWIW, this PEPhttps://www.python.org/dev/peps/pep-0514/ is what will enable us to fix the issue. Once implemented, we will be able to remove the dependency on VS configuration that prevents us working outside of VS.

— Reply to this email directly or view it on GitHubhttps://github.com/Microsoft/PTVS/issues/128#issuecomment-188469995.

[http://www.hawcpa.com/media/images/HAW-sig-logo.png] Chris Esworthy | Director, Business Consulting Services Five Concourse Parkway | Suite 1000 | Atlanta, Georgia 30328 P: (770) 353-5092 | E: Chris.Esworthy@hawcpa.com | F: (770) 351-5493 | M: +1 4045120650 | www.hawcpa.comhttp://www.hawcpa.com

Any tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or under any state or local tax law or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. Please do not hesitate to contact us if you have any questions regarding this matter.

Confidentiality Notice: This e-mail may contain information that is privileged or otherwise confidential. It is intended solely for the holder of the e-mail address to which it has been directed, and should not be disseminated, distributed, copied or forwarded to any other persons. It is not intended for transmission to, or receipt by, any other person. If you have received this e-mail in error, please delete it without copying or forwarding it, and notify us of the error by reply e-mail so that our address records can be corrected.

[zooba]

Issue #1469 is complete, so this should work in our next release. (Of course, there are a number of other changes throughout VS that may cause this to still fail, but it's not going to be the same reason.)

[Saibamen]

Still this same issue

[Saibamen]

dotnet build works but need to set MSBuildExtensionsPath32 system variable. Bug: https://developercommunity.visualstudio.com/content/problem/465815/msbuildextensionspath32-is-not-added-to-system-var.html