Skip to content
This repository has been archived by the owner on Dec 18, 2017. It is now read-only.

Bug - VSO Build Prebuild.ps1 CoreClr #422

Closed
Eneuman opened this issue Sep 4, 2015 · 8 comments
Closed

Bug - VSO Build Prebuild.ps1 CoreClr #422

Eneuman opened this issue Sep 4, 2015 · 8 comments
Assignees
Milestone

Comments

@Eneuman
Copy link

Eneuman commented Sep 4, 2015

Using the latest dnvm seems to break VSO builds.
(To reprocude this issue, follow the information in this post: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/deploy-aspnet5 )

My Prebuild.ps1 has this block:

echo "Installing clr"
& $env:USERPROFILE.dnx\bin\dnvm install $dnxVersion -r clr -Persistent
echo "Installing coreclr"
& $env:USERPROFILE.dnx\bin\dnvm install $dnxVersion -r coreclr

(The rest of it has not been changed)
Installing just clr works great and the build finish successfully.
But then I try to also install coreclr I get this error message:

Installing clr
Determining latest version
Downloading dnx-clr-win-x86.1.0.0-beta7 from https://www.nuget.org/api/v2
Installing to C:\Users\buildguest.dnx\runtimes\dnx-clr-win-x86.1.0.0-beta7
Adding C:\Users\buildguest.dnx\runtimes\dnx-clr-win-x86.1.0.0-beta7\bin to process PATH
Adding C:\Users\buildguest.dnx\runtimes\dnx-clr-win-x86.1.0.0-beta7\bin to user PATH
Installing coreclr
Join-Path : Cannot bind argument to parameter 'Path' because it is an empty string.
At C:\Users\buildguest.dnx\bin\dnvm.ps1:207 char:59

  • $RuntimeDirs = $RuntimeHomes | ForEach-Object { Join-Path $_ "runtimes" }
  • ~~
  • CategoryInfo : InvalidData: (:) [Join-Path], ParameterBindingValidationException
  • FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Microsoft.PowerShell.Commands.Join
    PathCommand

Determining latest version
Downloading dnx-coreclr-win-x64.1.0.0-beta7 from https://www.nuget.org/api/v2
Installing to C:\Users\buildguest.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta7
Cannot find dnx-coreclr-win-x64.1.0.0-beta7, do you need to run 'dnvm install 1.0.0-beta7'?
At C:\Users\buildguest.dnx\bin\dnvm.ps1:1549 char:9

  • throw "Cannot find $runtimeFullName, do you need to run '$CommandName in ...
  • CategoryInfo : OperationStopped: (Cannot find dnx...l 1.0.0-beta7'?:String) [], RuntimeException
  • FullyQualifiedErrorId : Cannot find dnx-coreclr-win-x64.1.0.0-beta7, do you need to run 'dnvm install 1.0.0-beta
    7'?
@glennc
Copy link
Member

glennc commented Sep 4, 2015

One quick thing to help diagnose this, if you switch the order so that it does coreclr first then what's the result?

I don't have all the code handy right now but I am wondering if persisting the change of desktop clr before installing coreclr is breaking something on the subsequent run. It is most likely a bug, but I want to narrow it down a bit.

@Eneuman
Copy link
Author

Eneuman commented Sep 4, 2015

I just tried to switch the order and got the same error message. Using only coreclr worked fine (& $env:USERPROFILE.dnx\bin\dnvm install $dnxVersion -r coreclr -Persist)

The error seems to occure when installing more then one runtime. I also tried to run it without -Persist but it didn't work ither.

I also noted that running "dnvm install 1.0.0.-beta7 -r coreclr" on my local machine and directly afterwards running "dnvm install 1.0.0.-beta7 -r clr" didn't work ither. I get the following error: "'dnvm' is not recognized as an internal or external command,operable program or batch file."
This used to work in the previous version.

@Eneuman
Copy link
Author

Eneuman commented Sep 9, 2015

Dup created 2 Days ago?
dotnet/aspnetcore#899

@Eneuman
Copy link
Author

Eneuman commented Sep 9, 2015

Adding the following two lines to Prebuild.ps1, just above "# install DNX", solved the issue.

$env:DNX_HOME="C:\Users\buildguest.dnx"
$env:DNX_GLOBAL_HOME="C:\Users\buildguest.dnx"

@iberodev
Copy link

This fixed that problem. I hadn't noticed that the path is actually C:\Users\buildguest\.dnx\

$env:DNX_HOME="$ENV:USERPROFILE\.dnx"
$env:DNX_GLOBAL_HOME="$ENV:USERPROFILE\.dnx"

@iberodev
Copy link

But I get now another problem when building in Azure in the execution environment

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.DNX.PackageManager' or one of its dependencies. The system cannot find the file specified.
2015-09-10T22:58:23.2641884Z          File name: 'Microsoft.DNX.PackageManager'
2015-09-10T22:58:23.2651888Z             at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
2015-09-10T22:58:23.2651888Z             at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
2015-09-10T22:58:23.2661886Z             at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
2015-09-10T22:58:23.2671891Z             at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
2015-09-10T22:58:23.2671891Z             at Microsoft.Dnx.Runtime.Loader.LoadContext.Load(AssemblyName assemblyName)
2015-09-10T22:58:23.2701891Z             at Microsoft.Dnx.Host.Bootstrapper.RunAsync(List`1 args, IRuntimeEnvironment env, FrameworkName targetFramework)
2015-09-10T22:58:23.2713059Z             at Microsoft.Dnx.Host.RuntimeBootstrapper.ExecuteAsync(String[] args, FrameworkName targetFramework)
2015-09-10T22:58:23.2722014Z             at Microsoft.Dnx.Host.RuntimeBootstrapper.Execute(String[] args, FrameworkName targetFramework)

As I understood it's due to an old web tooling. How do I modify that in Azure?

@dougbu
Copy link
Member

dougbu commented Sep 18, 2015

Self-assigning

dougbu added a commit that referenced this issue Sep 18, 2015
- #422
- previously used `$env:DNX_HOME` or `$env:DNX_GLOBAL_HOME` when undefined
- also ignores `$env:DNX_HOME` values such as ";C:\ProgramData\Microsoft DNX"

nits:
- use constants a bit more consistently
- remove trailing whitespace
@dougbu
Copy link
Member

dougbu commented Sep 22, 2015

416db7f

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants