Friday, June 29, 2012

Java Versioning

I am not a Java programmer, at least for last five or so years. So when I find the system requirement of some software that I need to install say it requires JRE version XX or higher, I am not so existed.

Their versioning, and naming as well, are confusing.

I think I did a bit of research on it before, but find what I learnt back then nowhere now. So this time again, did some Googling and found this http://www.ehow.com/about_6574616_java-jre-1_6_.html. This clears things out to a certain extent.

Another possibly very useful pointer would be http://java.sun.com/products/archive/.

For instance, today, I was looking for JRE 1.6 update 17. According to the explanation, I should find what I am looking for under “Java SE 6”. And the “Java SE Runtime Environment 6u17” found on the next page opened must be the one.

But again, what is this “6u17”? “Update 17 for Java (1.)6”? OK... But I believe they are trying to confuse us deliberately...

Tuesday, June 19, 2012

Embedded resource

I have the feeling that I faced this difficulty already in the past. But obviously did not write about it here. And so this time again, it took some time to figure out. Now I should keep it here.

It is to have some “resource files” embedded in the assembly and accessible from clients. Not about the other type of “resource files” where you have key/value pairs.

I used this technique in the past with a web part, and remember it was rather straightforward.

But then, this time, tried to do the same in a web application project and ran across a few points that required some Googling to overcome.

First of all, the project's AssemblyInfo file needs to modified. With hands? I did. http://aspnet.4guysfromrolla.com/articles/080906-1.aspx explains it.

Secondly, the “this.GetType()” in the following code does not work, with a web application project.

Page.ClientScript.RegisterClientScriptInclude("hoge", Page.ClientScript.GetWebResourceUrl(this.GetType(), "hoge.js"));

Correct me if I am wrong. I did not bother digging it further to confirm, but in a web app project, embedded resource files such as a javascript file are included into the project’s assembly together with the code behind classes etc. But the “this” does not point to it. Rather, it points to the temporal assembly the framework generates from the .aspx file accessed.

But GetWebResourceUrl method succeeds nevertheless. This makes its debugging difficult. The method succeeds and return a seemingly valid WebResource.axd path. It is then included into the response html. Client requests it and Bomb. The requested file is not found.

http://stackoverflow.com/questions/320484/webresource-hell-resource-cannot-be-found told me the fix.

Page.ClientScript.RegisterClientScriptInclude("hoge", Page.ClientScript.GetWebResourceUrl(typeof(whatever class that I am sure cohabit with the js), "hoge.js"));

I do not know how framework maps the long parameter of WebResource.axd request to my javascript. But it is certainly not in the temporal assembly the framework generates, represented by “this”, but in my project’s assembly. I have to specify it precisely.

Monday, June 4, 2012

Delete a Page Layout

I wanted to delete a Page Layout that I had deployed thru feature and used here and there already. The reason was that I became wanting to attach a preview image of my own to it. Thought it should be straightforward. A small modification to the feature. But it turned out not...

http://social.msdn.microsoft.com/Forums/en/sharepointecm/thread/273ef6a0-1f9f-46d8-9e9f-a70f81bc79cc

People here appear to have the same problem and discuss that the only solution is to delete the provisioned layout once and re-activate the feature.

But to delete a layout is not easy. Obviously I need to make sure it is not used by any page. I did that, by writing some code to list all pages using the layout and replacing with other layout. But still cannot. The famous “This item cannot be deleted because it is still referenced by other pages” message continues. It could be that the layout being not used by any page is not enough. Other places such as sites configured to have it available may need to be taken care of too, which I may have a closer look in future when I find time.

http://sharepointcodeblock.blogspot.com/2008/06/deleting-page-layout-or-master-page.html

In the meantime, I tried this too but no luck. Then realized that once I have moved it to a subfolder, even though I cannot delete it still, I can provision the new one, with my preview image. Not beautiful that the old one is always sitting in the subfolder, but at least I guess I have achieved what I wanted.

One more thing. I would like to keep this link as well for possible future reference.

http://blog.mastykarz.nl/provisioning-publishing-pages-features-declarative-markup/

Where I found the name of the feature which deploys the OOTB Publishing Page Layouts. Only by looking into it, I was able to find the name of the property (turned out to be “MasterPageDescription”) for the description (not very visible. appears for instance on _Layouts/CreatePage.aspx).

Friday, June 1, 2012

Applying a background image to a table row

 

http://snook.ca/archives/html_and_css/applying_a_back

It is often the case that to be sure that something is NOT possible is more difficult than to know how-to for things possible.

Wednesday, January 25, 2012

DOCTYPE Mobile

It took more than a day...

I was implementing mobile view of our internet-facing web site, which is on MS SharePoint 2010.

The page’s computed width gets 980px. But I could not find out where it comes from.

We had design company prepared their designs in HTML. So my task should not have been much more than a copy and paste. However, SP pages generated based on my mobile master page (basically of copy and paste) gets its computed width as 980px. Consequently, the contents gets all too small to read, while the HTML given by the design company shows nicely on mobiles.

Towards the end of a fruitless day, I noticed that the DOCTYPE definitions are different.

I did this mobile master page, based on that for PCs, which contains those SP controls and all. Its DOCTYPE is the usual:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

and I did not think I need to change this.

One defined in the design company’s HTML is:

<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">

With it, my SP pages look now OK on mobiles.

I am not an authority or anything. Do not know anything about the wapforum. I am writing this here just hoping that it may help you there tearing your hairs, not understanding where the hell the 980px width is coming from.

Wednesday, August 31, 2011

Migrate FrontPage web from IIS6 to IIS7.5

After weeks of try and error, I think luckily I have archived what I wanted. Not 100% but to an acceptable level.

100% is to copy everything. Users would not even notice that it is moved. But that was not possible. I could not figure out how after all. The thing missing is user permission. That, I think I would re-setup manually. At least the admins. Then ask them to deal with their colleagues.

First, I write about the method that did not work for our site after all. I believe that is due to something particular with our site, which I could not figure out. I may have achieved the 100% if I could.

You copy the site to your new 2008 R2 server using msdeploy tool. http://learn.iis.net/page.aspx/427/migrate-a-web-site-from-iis-60-to-iis-7/

You activate (“extend”) FPSE (FrontPage Server Extension) on the copied site.

At this point, you realize that the FP user permission are missing. This is what you should do: http://blogs.msdn.com/b/robert_mcmurray/archive/2009/10/12/migrating-fpse-roles-between-servers.aspx.

In case your site is simple enough, this is the end of the story. You have achieved the 100%. However, with our site, the server health check repair did not work. It ends with an exception, without telling me what it does not like.

Giving up to copy the permission, I uninstall FPSE once then re-extend. Failed too. Stuck...

Here is the workaround that I found. I cannot activate FPSE on the fully copied site. Let us then have an empty FPSE enabled site first, and then pour the actual site data into it.

I created a blank web site, activate FPSE, and finally copy files from the old server with the following command.

msdeploy -verb:sync -source:metakey=lm/w3svc/1551257136 -dest:metakey=lm/w3svc/2,computername=newserver -skip:objectName=dirPath,absolutePath=.+_vti.+ -skip:objectName=metakey,absolutePath=.+vti.+ -skip:objectName=metaKey,absolutePath="fpexedll.dll"

The “-skip” parts are my invention. No documentation found. They are to not to copy FP related stuff. It looks work. All webs are copied, seem working. I can create FP web on them.

Thursday, April 14, 2011

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...