Unable to Deploy to Azure RC-1

[ArieJones]

We are currently working on a web application and up until RC-1 we were able to deploy it successfully to Azure.
The project now has been updated to RC-1. Runs successfully locally when we debug it on IIS Express... but when we deploy to Azure all we get is a very long pause and then eventually a 502 error from the browser...

If we look at the event log about the only thing we see is the following entry for the below....

Is there a way in which we can get what EXACTLY is going on?

<Event>
<System>
<ProviderName="HttpPlatformHandler"/><EventID>1000</EventID><Level>0</Level><Task>0</Task><Keywords>Keywords</Keywords><TimeCreated SystemTime="2015-12-02T23:07:48Z"/>
<EventRecordID>812457593</EventRecordID><Channel>Application</Channel>
<Computer>RD00155D857487</Computer><Security/></System><EventData>
<Data>Process '7016' failed to start. Port = 29376, Error Code = '-2147023829'.</Data></EventData>
</Event>

[muratg]

@victorhurdugaci

How does your web.config look like?

[ArieJones]

Sadly it is basically the default one .... except for the log = true entry which we just switched on...

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified"/>
    </handlers>
    <httpPlatform processPath="%DNX_PATH%" arguments="%DNX_ARGS%" stdoutLogEnabled="true" startupTimeLimit="3600"/>
  </system.webServer>
</configuration>

[guardrex]

@ArieJones I list the known Azure Apps issues at the top of the "Application" section (this has been updated for RC1): aspnet/Hosting#364 (comment)

[guardrex]

@ArieJones Try ...

processPath="%home%\site\approot\web.cmd"

[ArieJones]

Sorry @guardrex I was actually following that discussion earlier today trying to determine what is up.
The change above with the procesPath gets me no joy unfortunately.

I think I am leaning towards the possibility that RC-1 possibly broke something in regards to the solution file being grouped in with the global.json file.... (sigh)....but it would appear that the only way I can really rectify that is to create another new project and then move everything over...

[guardrex]

@ArieJones Yes, I think there was an issue on exactly that point. I don't recall the repo where it was reported.

[guardrex]

@ArieJones ... but I think it was more along the lines of the global.json file being mixed in with the project files. I'll dig around and see if I can find that issue.

[ArieJones]

It was on this particular thread.... aspnet/Hosting#364 (comment)

[guardrex]

@ArieJones Yeah, that's it.

Do you have diagnostic logs turned on in the Azure portal? That was a problem recently for someone.

[victorhurdugaci]

@ArieJones a few questions to help us narrow down the issue:

1. How do you deploy?
2. What DNX runtime & architecture do you use? Is is the same when you run locally and publish to Azure?
3. Is there a body in the 502 response?

[ArieJones]

@guardrex no diagnostics

@victorhurdugaci

1. Through visual studio using the normal MSdelpoy template which worked up until now.
2. we are using the Rc1 x86
3. Nope

[ArieJones]

So after going in and creating a new solution last night... moving everything over... and then getting source control in line...

deployment works as expected...

When I get some time I will try to look into the whole global.json file residing in the same level as the project thing to see if that somehow helps the situation at all but right now I am short on time. I think in the long run it may help some people out whom are like me , migrating their project up through the various stages, and running into major hurdles when it comes RC time.

One note though is that it seems we are overcompensating everything with a .json file. Right now as I look at my project I have
global.json
bower.json
config.json
package.json
project.json
tsconfig.json
tsd.json

I mean at some point is there going to be some sort of consolidation of these or is this our newest form of 'Dll Hell' ... 2.0 of course...

[guardrex]

@ArieJones I'm glad it worked out for you. I'm adding a note to my comment. I'll say tentatively that this might be due to the global.json thing. I'll also run a test and see what happens when the file is placed alongside the project files. I want to see if the process failure is the same outcome.

[guardrex]

@davidfowl @anurse @ArieJones Yep ... it broke. Starting with this layout ...

.vs
src
    - artifacts
    - MyApp
        - bin
        - Controllers
        - Models
        - Views
        - wwwroot
        - MyApp.xproj
        - MyApp.xproj.user
        - project.json
        - Startup.cs
MyApp.sln
global.json

... and merely moving the global.json to this layout ...

.vs
src
    - artifacts
    - MyApp
        - bin
        - Controllers
        - Models
        - Views
        - wwwroot
        - MyApp.xproj
        - MyApp.xproj.user
        - project.json
        - Startup.cs
        - global.json
MyApp.sln

... results in a project that will run locally in IIS Express but breaks on the server. The app is unresponsive. The log shows ...

System.IO.DirectoryNotFoundException: The system cannot find the path specified. (Exception from HRESULT: 0x80070003)
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyLoadContext, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at Microsoft.Dnx.Runtime.Loader.PackageAssemblyLoader.Load(AssemblyName assemblyName, IAssemblyLoadContext loadContext)
   at Microsoft.Dnx.Host.LoaderContainer.Load(AssemblyName assemblyName)
   at Microsoft.Dnx.Runtime.Loader.AssemblyLoaderCache.GetOrAdd(AssemblyName name, Func`2 factory)
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyName(AssemblyName assemblyName)
   at Microsoft.Dnx.ApplicationHost.DefaultHost.GetEntryPoint(String applicationName)
   at Microsoft.Dnx.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
   at Microsoft.Dnx.ApplicationHost.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Dnx.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider serviceProvider)
   at Microsoft.Dnx.Host.Bootstrapper.RunAsync(List`1 args, IRuntimeEnvironment env, String appBase, FrameworkName targetFramework)
   at Microsoft.Dnx.Host.RuntimeBootstrapper.ExecuteAsync(String[] args, BootstrapperContext bootstrapperContext)
   at Microsoft.Dnx.Host.RuntimeBootstrapper.Execute(String[] args, BootstrapperContext bootstrapperContext)

... and I wouldn't be surprised if you said 'that's by design.' However, let me know if you want me to create a fresh issue for this, and I'll open it (in dnx?).