IronRuby.Rack isn’t passing the windows credentials through, but uses
the
credentials from the app pool so using a user + password in database.yml
did
change the error message.
I created my rails application under a virtual directory and then it
gets
confused about where it’s supposed to go
No route matches “/mocktwitter” with {:method=>:get}
When I give it a proper site it’s a lot happier and will show me stuff
but
it still won’t display images, it’s odd because it will correctly read
the
css file from disk but not the image files.
The image doesn’t seem to be handled by the rack handler so I wonder why
it
won’t show up at all. I verified permissions and gave everyone full
control
on that set of files.
I did build my IronRuby.Rack with the strong named RC3 assemblies
because
with a debug version it was a lot slower. Now initial startup time is
comparable to an ASP.NET application with a couple of referenced
assemblies:
+/- 10 seconds on my machine (core i7 w/ 10000RPM disks) when it needs
to
initialize a new application.
I am unable to debug the application though. If I put
System::Diagnostics::Debugger.break somewhere it will correctly break
there
but eventually visual studio (2008 and 2010) will just get tired of it
and
claim they have to quit. I’ve seen that the debug windows gives me a
lot of
information and I was hoping that there would be some useful information
there for me but because visual studio quits right at the interesting
moment
I’m unable to figure out what’s going on as nothing is printed in the
sysinternals debugvw application.
I am unable to debug the application though. If I put
System::Diagnostics::Debugger.break somewhere it will correctly break there
but eventually visual studio (2008 and 2010) will just get tired of it and
claim they have to quit. I’ve seen that the debug windows gives me a lot of
information and I was hoping that there would be some useful information
there for me but because visual studio quits right at the interesting moment
I’m unable to figure out what’s going on as nothing is printed in the
sysinternals debugvw application.
You may also want to try WinDBG with the SOS extension. Here’s slides
with code and examples on using WinDBG to debug .NET applications:
What I’d try is using the File menu to attach to the process, then when
it breaks typing in “.loadby sos mscorwks”. Next type in “sxe clr” and
then “g”. It will now break on all CLR exceptions. You can type
“!printexception” to see the exception details when it breaks, and “g”
to make it go again. You can also type “!help” to see all of the SOS
commands.
The issue just seems to be that the process is dying before Visual
Studio can properly attach. Ivan, try using "
System::Diagnostics::Debug.assert false" which will pop up a dialog box,
thus blocking the thread, but without using the “int 3” x86 instruction
as System::Diagnostics::Debugger.break would. The latter might cause
some issues.
Also, could there be any issue with the fact that ASP.Net is running a
service? Some dialog boxes might be getting hidden since services run in
their own hidden workspace/workstation (I think)
In that case, windbg might help. It’s potentially a bit more robust
since it offers fewer features. Btw, I often disable “Tools | Options |
Debugging | Enable property evaluation and implicit function calls†in
Visual Studio so that it does not try to implicitly run code in the
process being debugged when you hit a breakpoint or step over a line of
code. If I need to evaluate some property when stopped at a breakpoint,
I do that explicity using the Immediate Window.
On Mon, Mar 15, 2010 at 7:18 PM, Shri B.
<[email protected]mailto:[email protected]> wrote:
The issue just seems to be that the process is dying before Visual
Studio can properly attach. Ivan, try using "
System::Diagnostics::Debug.assert false" which will pop up a dialog box,
thus blocking the thread, but without using the “int 3” x86 instruction
as System::Diagnostics::Debugger.break would. The latter might cause
some issues.
Also, could there be any issue with the fact that ASP.Net is running a
service? Some dialog boxes might be getting hidden since services run in
their own hidden workspace/workstation (I think)
When using IronRuby.Rack and debugging the ruby code running, keep a few
things in mind:
Enable debug mode for DLR code in your app’s web.config (in the
Microsoft.Scripting section).
Because VS breakpoints in blocks don’t work yet, using
Debug.Assert will do the job.
IIS has a timeout of 60 seconds per request, which can be
annoying when debugging. In the AppPool configuration that your
application is running in try to max the timeout out so the process you
want to debug stays around.
Use WinDBG if you want to “man upâ€, but the VS debugger will be
Rails::Initializer.run do |config|
config.action_controller.relative_url_root = “/IronRuby.Rails.Example”
if ENV[‘RACK_ENV’] == ‘production’
…
end
Also, I usually set up a separate AppPool, and set it to run as a
specific Windows user, so I can grant read-only permissions to that user
for the Ruby stdlib/gems, and read-write access for the app. Then you
don’t have to grant permissions to IIS_IUSRS for all your stuff.
~js
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.