For @GuardRex about dnx-watch-iis

[guardrex]

I'll get back to u in a few hrs. I'm skating in irvine this am then off to
the gym.

Yeah ... Let's see if we can figure out the prob, but note that I did
explicitly follow your steps. I didn't have luck with the dnvm approach. It
worked with a dnx process path.
On Nov 23, 2015 10:31 AM, "Derek" [email protected] wrote:

@guardrex https://github.com/GuardRex

with the dnvm.exe PATH and the run ... ARGS, the app/dnx wouldn't respond
to any requests. It wasn't until I changed the PATH and ARGS to what I show
that the app would respond (and dnx-watch worked, too).

Figured we could sort this out here rather than blasting everyone on the
announcement's discussion thread.

Did you get any events in the Application event log or output from stdout
from the HttpPlatformHandler? Would you try changing the startupTimeLimit
on the HttpPlatformHandler from 60 hours to something like 30 seconds and
see what the event log and stdout logs say?

—
Reply to this email directly or view it on GitHub
#2.

[tuespetre]

Sounds good. It will be interesting to see what the diag shows.

[guardrex]

@tuespetre Ok, I'm back. Nice day. Had a nice 6 mile skate + lift.

Anywho ... I did chop down the timeout, and I forgot what happened. I think the module timed out to like a 500.x but the module log never was even generated.

Let me go back and run that sequence again with your walkthrough settings and confirm the behavior, then we can pick up from there.

brb ...

[guardrex]

@tuespetre No dice. It doesn't even timeout properly. It literally doesn't timeout at all. Fiddler shows the request gets no response, and there is no log generated. There is an event for the failure that indicates that the process fails to start.

When I go with ...

DNX_PATH: C:\Users\XXXXX\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-rc1-final\bin\dnx.exe
DNX_ARGS: --project .. watch --project .. --dnx-args web

... it works great.

I guess my broader question is, what difference does it make? I mean was there something about the dnvm approach that confers some benefit?

[tuespetre]

What is the text of the event indicating that the process failed to start?

The reason I used dnvm directly is because dnvm adds the invoked dnx version to the process's PATH variable, so dnx-watch can find dnx. Otherwise, the only way dnx-watch would find dnx is if you had added a particular dnx version to the system PATH yourself, or to the specific user's PATH. Those were my findings with rc1, anyways.

[guardrex]

... or do what I did ... invoke dnx directly. After all, you're just invoking it, right? You can invoke it with the watch command as I did, and it seems to be happy with it; although, I admit to no real testing ... I just modified the app's Response.WriteAsync(...), saved the file, and refreshed to confirm the watch was working.

Anyway ... here's the event when I try it your way.

[guardrex]

@tuespetre Hey Derek ... how's it going? I got slammed ... I think you probably got busy, too. Did you have any thoughts on the process crashing for me? If not, no worries. I think our discussion highlighted two ways that someone could go and either of which might work. I'm just glad that it did finally work on my end ... pretty cool stuff.

[tuespetre]

Yup, been very busy... haven't looked at it. 🍻

[guardrex]

No worries. I was just curious. I think it can be left where we left it.