No real alternative yet for FrontPage Server Extension

After days of frustrating analysis, my conclusion at the moment is to stay with the now-has-become-a-third-party-product FPSE.

My requirements are:

1. I, the server administrator, do not want to do much. I do not want to be called to intervene each time a web site is to be created. Once I have appointed developer A for admin of web site host/siteA, I do not want to have to intervene for host/siteA/siteA1 etc. Moreover, when he has got a colleague who assumes the same role as him, he could do the necessaries.
2. Operations for developers such as managing the web site permission, deploy their codes, should be straightforward.

With FPSE on a 2003 box, it has been near perfect. Except for one thing. No means that developers can verify if a folder is setup as “application”. They can turn a folder into an application, but cannot verify.

The story started when we start thinking of upgrading our web server, currently IIS6 on 2003 box, to IIS7.5 on 2008 R2. Soon I came to know that FPSE is no more supported. There is one as a third party product, but not from MS. Not yet for IIS7.5 but it is said to become available soon.

What is then the MS’s alternative? None that I can see.

Visual Studio 2010 supports the followings for code deployment.

1. FPSE
2. FTP
3. Network share
4. Web Deploy # Only for Web Application Projects
5. WebDAV # Some say you could, by mapping it as (or like) a network drive.

I do not know if you agree. But to me, 2 and 3 seem going back to the stone age.

4. Web Deploy should be the first choice. It is new so must be better. But some say that converting a web site project to web application is not as straightforward as you may think. In addition, it does not fulfill one of my requirements above. The server administrator has to do whole a lot!!

If I setup the “Application” host/siteA for developer A, he could autonomously do the child application host/siteA/siteA1, by importing the siteA1 application with the IIS7 Remote Administration. (I so far fail to do the same with VS though) But he cannot give the permission to his colleagues by himself. It is understandable. When the server administrator setup an application, he needs to not only configure IIS Manager Permission but folder permission as well, while with FPSE you do all these in one go.

Finally, 5. WebDAV too appears to have the same shortcoming, lacks the permission management delegation capability that we want. It is said “The IIS7.* WebDAV extension module supports per-URL authoring rules, allowing administrators to specify custom WebDAV security settings on a per-URL basis.” But as it reads, it is for (server) administrators only. When you connect to a site or an application, with the IIS7 Remote Administration, you do not have the WebDAV Authoring Rules icon. And to connect to the server (then you have the icon), you need to be the administrator...

And above all, needing to map WebDAV folders for publishing web sites from VS does not sound to me an optimum solution...

CSS delivered as Content-type: application/octet-stream

I do not know if this could ever be any benefit of anybody. It could be just that there is something wrong with our servers…

On our site, sometimes (it appears) CSS files are delivered to clients as Content-type set to application/octet-stream.

The story starts as a few colleagues report pages are displayed ugly without styles on Firefox and Chrome. OK on IE.

I found that the CSS is stored in the browser's cache as application/octet-stream. This is tricky because once you clear the cache and go to the page again, the CSS would be downloaded OK.

There seems nobody having similar issue, or at least reporting to the net. I tried to come up with an own workaround.

I wrote an HttpModule to verify if responses for css files are generated correctly as Content-type: text/css, and correct it if not. It writes into the log file each time it find such a problematic response. By the way, in the course of writing the module and testing it, I found that IE applies styles even if it receives the css file as application/octet-stream. This is why the problem has been reported happening only on Firefox and Chrome. Furthermore, for some css, those that SharePoint generates, you can change the Content-type (to application/octet-stream for the testing) in the MIME type configuration of IIS. However, those of our own creation, those in the /Style library folder, come as text/css, even after the change in the IIS’s MIME section. So it is SharePoint that controls it.

Towards the end of the first day after the module is plugged in, the module reported that it did the Content-type correction. And a lot! We have two Web Front End in a farm. Both connect to one single Content database. Each web server generates those mal formed css responses at different timings.

Each has a IISRESET scheduled job. At different times of a day, obviously. Each generates the problematic responses after the IISRESET and stops doing so when the application pool gets recycled. (it gets recycled when the memory usage reaches the threshold)

Sh*t!! I should have requested pages from the server while the module there was reporting the problem!! I could have verified that my Content-type correction does the trick. No worries. It would come again, I guess…

Post from Windows Live Writer

 

Let us see how it goes…

ASP:Menu SkipLink

For those who landed here looking for a solution together with the cristal clear explanation, sorry, no, I do not have one :-(

Symptom.
We have migrated our internet facing site from SharePoint 2007 to 2010. We (needed to) have redone our custom master page. We did so having the 2010 minimal masterpage http://code.msdn.microsoft.com/odcSP14StarterMaster as the basis.
Then we found the Global Navigation menu, which uses the SharePoint:AspMenu control (I think it behaves pretty much the same as ASP:Menu), appears a little lower than it used to.
It does so to me everywhere. I have IE8 and FF3.5 on my PC. But later realized that it is OK on their old versions; IE7 and FF1.5.

The only difference is with the so-called "skip navigation link". It is visible (and thus takes some space) with the new master.





It was invisible with the old master.





The above screenshots are from FireBug. But up to now, I do not know what makes it "visible" or "ïnvisible".

My solution for the time being is to set DOCTYPE of the masterpage back to XHTML 1.0 Transitional. Do not ask me why...

The above mentioned minimal masterpage comes as XHTML 1.0 Strict. It is pity that I had to go back "Transitional". But this is the only workaround that I so far found.

Install Perl Modules

This is really my personal memo.
I have installed a perl module for the first time in my life and actually learned a lot, so just like to keep what I did here for future reference.

The command is as simple as this. There is a switch -MCPAN for the executable itself to add a module. I log the output. Again this is just for my reference.
# perl -MCPAN -e "install Time::Period" >install.perl.time.period.log 2>&1

Actually, this failed.
It was unable to find the package, Period-1.20.tar.gz, at (in our environment) http://cpan.mirror.fr/.
I found the file at http://search.cpan.org/CPAN/authors/id/P/PR/PRYAN/Period-1.20.tar.gz. So how can I change the host (that perl goes to get packages)? You do as follows.

# perl -MCPAN -e shell <- go into the shell mode
cpan shell -- CPAN exploration and modules installation (v1.61)
ReadLine support available (try 'install Bundle::CPAN')

cpan> o conf urllist <- show the currect host list
urllist
http://cpan.mirror.fr
http://cpan.mirror.fr/
Type 'o conf' to view configuration edit options

cpan> o conf urllist pop
cpan> o conf urllist pop <- do this twice to remove the unwanted hosts

cpan> o conf urllist push http://search.cpan.org/CPAN/
cpan> o conf urllist push http://cpan.mirror.fr <- not really care but just liked to keep what were there
cpan> o conf urllist push http://cpan.mirror.fr/

cpan> o conf urllist
urllist
http://search.cpan.org/CPAN/ <- now perl tries this site first
http://cpan.mirror.fr
http://cpan.mirror.fr/
Type 'o conf' to view configuration edit options

cpan> o conf commit
commit: wrote /usr/lib/perl5/5.8.0/CPAN/Config.pm

cpan> quit

Try the first command again, and GOTCHA!

EventLog.WriteEntry from a ASP.NET page

The page is run as NETWORK SERVICE. I would not ask you to either change it to LOCAL SYSTEM, or put NETWORK SERVICE to the administrator group.
The later sounds quite stupid. But a colleague of mine did find somebody proposing it as a solution on the net.

The simplest code fragment that you would find at many places on the net should look like the following. I too found it on the net.

protected void Page_Load(object sender, EventArgs e)
{
// Create the source, if it does not already exist.
if (!EventLog.SourceExists("hoge"))
{
//An event log source should not be created and immediately used.
//There is a latency time to enable the source, it should be created
//prior to executing the application that uses the source.
//Execute this sample a second time to use the new source.
EventLog.CreateEventSource("hoge", "Application");
// The source is created. Exit the application to allow it to be registered.
return;
}

// Create an EventLog instance and assign its source.
EventLog myLog = new EventLog();
myLog.Source = "hoge";

// Write an informational entry to the event log.
myLog.WriteEntry("hello world.");
return;
}

This would not run as NETWORK SERVICE. However, there is actually only one instruction that cannot be performed with NETWORK SERVICE privilege. It is the “CreateEventSource()”. The instruction to actually write an event, WriteEntry(), runs with no problem.
Since CreateEventSource() needs to run only once, you either take it out and run in a separate console app, or runs the above code only once as LOCAL SYSTEM then change it back to NETWORK SERVICE immediately after that.

[MOSS 2007 public facing site] access to MS Office documents in Document Library

I am less and less certain if this is a right product…
This is THE most incredible and discouraging experience that I ever had with this product, which I have been working on to maintain our public internet site.

First of all, MANY MANY MANY thanks to the author of this blog post.
http://www.theblackknightsings.com/RemoveLoginBoxWhenAnonymousUsersDownloadOfficeDocumentFromSharePointSite.aspx
# BTW, the design is very funny. I thought it was a genuine error screen at the beginning.

The explanation is very clear, and so is the code. So I went straight plugging it in to our production site.
# I have at least compiled the DLL myself, and did a bit of test though.

We know that this product i.e. SharePoint is now widely used, especially with intranets, sites for collaboration and so on, where you know the users, they are all authenticated. However, for public facing internet sites such as ours where majority of users are anonymous, there are points overlooked, including ones as obvious as this one. And we users by ourselves need to apply workarounds… Hope with the coming 2010, it comes as a WCM product fully ready for public sites.