Hit this today attempting to install WATIR on my current development box. The domain has a proxy server that has only occasionally caused me issues, but now I was unable to use gem to install WATIR unless I could configure the proxy. The correct syntax was harder to find than I expected, so I thought I would capture it here:
To configure a proxy server, with associated username and password, execute this in your command window: (obviously replace out the relevant bits)
set HTTP_PROXY=http://username:password@domain-proxy-name:8080
The thread that I happened to find this on was here, I am sure there are others
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/fdcc4268553756de?pli=1
Running gem update --system Now succeeded, however my attempt to run gem install watir kept timing out, not sure why, so I fell back to downloading the gem file to disk then running the install with a local path gem install c:\path…\watir-1.6.2.gem and I was up and running.
© Copyright 2009 - Andreas Zenker
For a long time I have wanted to be able to do this without it being a 2 day ordeal, or having to beg IT to open up some ports etc. Seems to me the last time I looked this was a lot harder than it is now. Has it gotten easier or did I just assume it was annoying and not really consider it? Not sure, but it has been a real life-saver on recent projects, especially SharePoint. Here are the links that got me up and running quickly.
- Best one to start with talks you thru the basic setup requirements:
http://www.wictorwilen.se/Post/How-to-get-Remote-Debugging-work-properly.aspx
- Another take on the same setup:
http://www.sharepointblogs.com/llowevad/archive/2008/04/10/remote-debugging-gac-d-assemblies-in-sharepoint.aspx
- On 2003 and 2008 servers you can have multiple w3wp.exe processes running, how to know which one matches your app pool
http://blogs.thesitedoctor.co.uk/tim/2007/10/16/Identify+Which+Application+Pool+Is+Associated+With+Which+W3WPexe+Process.aspx
the above link refers to 2003 and before and makes use of cscript.exe, on 2008 you need a different script. Here is a sample batch file. It will list all the active worker processes along with their process id and app pool name.
1: cd %systemroot%\system32\inetsrv
2: appcmd.exe list wp
3: Pause
- When you attach to a worker process for a long debug session, IIS may kill the process while you are debugging since, to its health monitor, it appears to not be responding. How to set IIS and your app pool to leave you alone and let you work.
http://msdn.microsoft.com/en-us/library/bb763108.aspx
- The last thing you will most likely want is to have your current symbol files deployed to the server's GAC as well. The folders are hidden so this will make the process easier. You can copy the symbols from a share on your dev machine or build server or deploy them locally and then copy them from there. This last project I had three assemblies one each for Branding, Controls and Business Logic and one for Web Parts. This simple batch would deploy my symbol files each time I deployed to the server and I would be all set up to debug when I needed to.
1: copy \\BUILD_SERVER\PROJECT_NAME.Branding\bin\Debug\PROJECT_NAME.Branding.pdb c:\windows\assembly\gac_msil\PROJECT_NAME.Branding\1.0.0.0__838b0bf4b15f93ce
2: copy \\BUILD_SERVER\PROJECT_NAME.Controls\bin\Debug\PROJECT_NAME.Controls.pdb c:\windows\assembly\gac_msil\PROJECT_NAME.Controls\1.0.0.0__838b0bf4b15f93ce
3: copy \\BUILD_SERVER\PROJECT_NAME.WebParts\bin\Debug\PROJECT_NAME.WebParts.pdb c:\windows\assembly\gac_msil\PROJECT_NAME.WebParts\1.0.0.0__838b0bf4b15f93ce
4: pause
© Copyright 2009 - Andreas Zenker
I was posting a WPF question on stackoverflow and I took a few minutes to tie up loose ends on a question I had asked back in September about how to best go about developing web parts for SharePoint as an ASP.NET developer. I was just getting started out with rough proto-types of what the client was requesting and was doing all my mock-ups in ASP.NET web forms. I didn't want to be "slowed down" by any SharePoint learning curve. I was comfortable in ASP.NET and just wanted to be able to deploy my ASP.NET user controls into SharePoint and not get my hands dirty actually learning SharePoint. I asked the question hoping for a quick work-around that would fit my needs. So here I am 3 months later, a SharePoint survivor. Question is: would I start the same way if I had it to do again?
Not a chance!
Disclaimer: To be honest, I did get some good responses to my question with suggestions on work-around's that are available such as web parts that have been written to host ASP.NET user controls. Also, I was informed that you can actually deploy both user controls and even full ASP.NET pages to the SharePoint hive (folder structure where disk-based SharePoint resources are stored) and they just work, though your access to the SharePoint object model will be limited. These are viable options that will get you up and running fairly quickly. However, in my brief experience, it is not the way I would choose to go.
The problem with SharePoint, in my jaded opinion, is that it is too easy. In fact it could be called the new Access. You can read some articles, follow a few tutorials, point and click your way to version 1.0 of your internal HR site and call yourself a SharePoint Developer. Yes, SharePoint is definitely easy....at first. However, that doesn't cut it in the long run and you should be very afraid of version 2.0 when it comes along. It is easy to install a new blog or department calendar, set up a page for HR to start uploading files and photos of the company picnic. That's all well and good, but we are not talking about out-of-the-box web parts here. Now we've moved on to custom web parts that need to be built from scratch and be robust, secure and user friendly. This is when we hit it, the SharePoint learning curve, more like a wall really, or a cliff with a whole pile of bleached bones at the base. Fact is, if you are a serious developer, you are going to hit this wall sooner or later. The last 20% always gets you when you are working with a platform that is designed to make it all "easy". That being the case, make the conscious decision to hit the wall sooner. If you put off the "learning wall of despair" too long, it will hit when you at a point in your timeline when you can't afford any unpredictable delays. Others, and even you, may think you are "done" ("it's all coded we just need to deploy it and we're good"). For some reason project managers and stakeholders take issue when "done" turns into a 3-6 week delay as you come up to speed with all the goodness that is SharePoint deployment. So, when starting on your first SharePoint project, dive in, the waters tepid! In the long term you, and your project will be better for it.
As a side point, a comment on the value of having SharePoint as a skill in your toolbox:
SharePoint will never be my choice of a application platform to work with. However life, as it turns out, is not all about what we want. Who would've thunk it? All that being said, it is a skill and it is not an easy one to acquire an expert level understanding of. I think a more accurate label for SharePoint, as the blog title indicates, is the new Oracle, in that it is hard, complex, has an almost a complete lack of effective tooling, is about as developer friendly as wet punch cards, and the majority of developers who claim to have SP skilz, couldn't code their way out of a cardboard web part. Call me cynical, but I think it's a fairly accurate assessment. Match that situation with a high client demand for SharePoint development and you have, in my opinion, a technology worthy of black turtlenecks and designer level salaries. So I guess this post proves you can find a silver lining in any technology. :-)
If you are faced with a SharePoint learning wall, grab the opportunity and learn it well. Don't become another SharePoint/Access developer.
Here are some links that helped me get up to speed.
© Copyright 2009 - Andreas Zenker