Posts Tagged ‘iis’
July 7th, 2017
I seldom use F5 (start the application in debugging mode in Visual studio) but instead run it normally and connect the debugger only when I need to.
Connecting the debugger takes a measurable amount of time so with a faster turnaround I can keep focused better.
I also leave IIS running all the time. It does shadow copying so there is no need to restart anything.
I have recently switched from IIS to IIS express while developing and hence need to have it running all the time. That I do through the command prompt with
1
| "c:\Program Files\IIS Express\iisexpress.exe" /path:C:\PathToMyWeb /port:32767 |
where path is the path to the site (where the web.config resides) and the port is what you see in the web project properties or in the web browers’s address bar the first time you hit F5.
It has the nice side effect that I can see all the http requests I do in the command window, a light weight current log of sorts.
October 6th, 2014
Honor those who should.
Setting up a new Web site and then connecting it to Sqlserver is a breeze if one uses the development web server.
But if one wants to use the real McCoy, i.e. IIS, there is more work.
iis apppool: http://www.selfelected.com/iis-7-iisapppool-lightly-explained/
Why use the real IIS when it is so cumbersome? Because it looks more like the real production environment.
How do I debug? Like this:
Start Visual studio i in administrator mode. (if one doesn’t, VS is helpful with this)
Then ctrl-alt-p (menu:debug:attach to process) and choose the w3wp.exe process, with the right user name. Attach. Debug.
September 6th, 2014
I finally managed to write through Debug.WriteLine to Sysinternals DebugView through reading this article. Kudos to the author.
If the original article disappears; here is the recipe in short:
Start Sysinternals Debugview as administrator. Make sure Capture global win32 is checked.
Make sure Visual studio is not attached as debugger because when you run the VS debugger it hogs all information. (In VS you can find the output in the Output window with Show output from Debug.)
Besides Debug.WriteLine also play around with Trace.WriteLine and Console.WriteLine.
July 18th, 2011
If you wonder about what IISAppPool is, please follow this link: http://learn.iis.net/page.aspx/624/application-pool-identities/ or this same one with an easier to read URL.
It is an almost-user that IIS uses for running each web in its own space. One can do the same with ordinary users but it seems to be to much of a hassle for us regular developers.
The article doesn’t explain everything; but exactly what I needed. Then together with http://stackoverflow.com/questions/4877741/access-to-the-path-is-denied and especially the comment by Hans Passant it made me solve an access problem.
October 18th, 2009
If one uses trusted connection to a sqlserver database under Windows 7 and II7 one might get the error message “Login failed for user ‘IIS APPPOOL\DefaultAppPool’.” when trying to run a web application. There are several articles for this but all points to a different GUI than mine (earlier versions of Windows7/IIS7?).
Update: as I lightly noted, to give the apppool SystemLocal rights is Not the right way to go.
Set up the application pool in IIS
Fire up Internet Information Services Manager. (windowbutton-iis-return)
Find the Application Pools item in the Connections toolbar. One can reuse the default application pool or create a new one. Go for the latter since it is slightly more complicated and hence more fun.
or in Win8:
(I don’t grok what Managed pipleline mode does.)
Select your newly created application pool and the advanced settings. Change the Process model to LocalSystem.
(I had planned to create a “better” account with the proper limited rights but ran out of time. Someone else…?)
Update: Don’t change to LocalSystem, instead add the user to allowed SQLServer logins as noted in the bottom here. I suggest “IIS AppPool\MySite” for now.
The recommended Microsoft solution is to create a separate account. However, if your solution is small, you can instead add the ‘IIS APPPOOL\DefaultAppPool’ user as a database user in your SQL instance, then providing the proper ‘User Mappings’ to the databases you need the DefaultAppPool user to access. You may not necessarily be able to search for this user, but you can still enter it in the ‘Login name’ field in the “Login – New” window as “IIS APPPOOL\DefaultAppPool” (without the quotes).
Follow this link as a reference and pay attention to the last post: http://social.msdn.micro…-4a71-a448-3e3eef9ee404/
Application pool settings
Getting to advanced settings.
Application pool advanced settings
Site settings
Now change your web application to use this application pool. This could be made simpler by moving the menu for this to the same place as the other menus. To make the story short – select your site and look to the right of the IIS manager.
Site advanced settings.
Site advanced setting IIS7.
Application pool.
Application pool in IIS7.
Set up Sqlserver
Honour those who should.
To add a new user to SQLServer go to your database->security and add user connected to IIS APPPOOL\DefaultAppPool. This way the user can log in to the database.
Sqlserver -> new login.
New login to database. Don’t forget to change default database to appropriate.
Then go to the SQLServer->security and add this user to be allowed to login to the server through the user and properties.
The users of a database.
That is all there is to it.
April 11th, 2009
In an earlier article (or here) I mentioned a time saver for web projects where I recommended attaching to the process instead of restarting every time.
Today I invested time in creating a macro for attaching to the Nunit process. It was easy.
– Instead of learning all commands just record a new macro (menu->tools->macro->record temporarymacro) and connect to the process of choice.
– Then open the macro explorer (menu->tools->menu->macro explorer) which opens a toolbox. There is a (new) module called RecordingModule. Open this.
A new IDE opens with something like:
Sub AttachToNUnitProcess() ' MsgBox("AttachToNUnitProcess.Start") Try Dim dbg2 As EnvDTE80.Debugger2 = DTE.Debugger Dim trans As EnvDTE80.Transport = dbg2.Transports.Item("Default") Dim dbgeng(1) As EnvDTE80.Engine dbgeng(0) = trans.Engines.Item("Managed") ' Can be "Native". Dim proc2 As EnvDTE80.Process2 = dbg2.GetProcesses(trans, "MDG-VILTERSTEN").Item("nunit.exe") proc2.Attach2(dbgeng) Catch ex As System.Exception MsgBox(ex.Message) End Try ' MsgBox("AttachToNUnitProcess.Slut") End Sub
– Testrun your macro in Visualstudio just to make sure it runs properly.
– In the macro editor, create a new Module and copy the code you just created. Rename module and method. Save.
– Back in Visualstudio, Macro explorer, your new module should be visible. “Should” – one might have to restart Visualstudio or the toolbox or something. It should be runnable directly from the Macro explorer toolbox.
– Create a new menu (menu->tools->customize …) and attach your macro. You find it under “Categories/Macros”, just drag it to your new menu or the menu bar.
Now attaching to a process is just a click or keystroke away.
Some more info is found here: http://msdn.microsoft.com/en-us/library/hdf2d1z8(VS.80).aspx.
Update: I debugged a web app for a while yesterday and Wow! – what a difference between 3 clicks and 1 click, or 3 keystrokes and 1 keystroke. Besides being simpler it also connected faster when the GUI didn’t have to render and didn’t have to wait for me. Why haven’t I done this years ago? What else is there I should have done years ago?
Update: I created a new menu and items for every macro I use. So Fast to use!
There is something that bothers me though. Some menus dissappear after I restart VSNet, I don’t know why.
The macros are easy to start also without having created a menu for them. Just alt-F8 and then arrow keys to find the right macro and start it with return.
Update: If I only use 1 macro I can use “run last macro” with shift-ctrl-P. I am using it right now because I am too lazy to create a new menu and stuff.
April 11th, 2009
When debugging aspnet solutions a lot of time is wasted on restarting the debugged application. A real time saver is to connect to the process to avoid restarting.
This is done like so:
– When a new bug is found don’t stop the web browser, instead detach from the process (menu->detach->detach all).
– Update the code to correct the bug.
– Set a breakpoint.
– Connect (menu->attach to process->[find the process, it is called something like iis or aspnet]->attach) to the process.
– Reload the web browser.
There are some caveats. Like when using Webform the viewstate is tightly connected to the controls on the form so it is not always possible to connect.
But for the most times this is a great time saver.
—-
When you have done this a couple of times even this takes long time. So fire up the macro recorder and do the recipe above. Then run the temporary macro. Running the macro is way faster than doing it manually. I guess it is all the GUI stuff that takes time.
Or store the macro in VS and create a button and/or a shortcut.
—-
Update: use shift-ctrl-P to run last macro. Nice if one is too lazy to create a menu.