Trying to upgrade from revision 3399 to 4864 :)

This is the place to report bugs and get support. When posting in this forum, please always provide as much detail as possible.

Please do not report problems with a custom build or custom code in this forum. If you are producing your own build from the source code and have problems or questions, ask in the developer forum, do not report it as a bug.

This is the place to report bugs and get support

When posting in this forum, please try to provide as many relevant details as possible. Particularly the following:

  • What operating system were you running when the bug appeared?
  • What database platform is your site using?
  • What version of mojoPortal are you running?
  • What version of .NET do you use?
  • What steps are necessary to reproduce the issue? Compare expected results vs actual results.
Please do not report problems with a custom build or custom code in this forum. If you are producing your own build from the source code and have problems or questions, ask in the developer forum.
This thread is closed to new posts. You must sign in to post in the forums.
3/12/2009 6:43:02 AM
Gravatar
Total Posts 488

Trying to upgrade from revision 3399 to 4864 :)

Joe,

after a long pause I tried to upgrade my pgsql site from revision 3399 to 4864. Some notes and questions.

1. mojoportal-complete-vs2005.sln did not compile as \mojoPortal.Features.UI\Services\Metaweblog\Services\MojoDataService.cs uses constructions not supported by old .Net runtime. For now just commented out sorting of blog categories.

2. Setup page has thrown the following exception.

Running script mojoportal-core - 2.2.4.9 - 00:00:01.0469152
Npgsql.NpgsqlException: constraint "mp_bannedipaddresses_pkey" of relation "mp_bannedipaddresses" does not exist Severity: ERROR Code: 42704

Changing "mp_bannedipaddresses_pkey" to "pk_bannedipaddresses" in the script solved the problem, after that all the upgrade scripts passed.

3. Skins that I used disappeared from svn, so I needed to edit the database to set the skin and access admin menu.

4. As far as I can see in web.config, the solution is now targeted to .Net 3.5. What should I change to still target .Net 2.0 (for a while, before upgrade of my projects)?

3/12/2009 7:45:12 AM
Gravatar
Total Posts 18439

Re: Trying to upgrade from revision 3399 to 4864 :)

Hi Alexander,

Nice to see you again!

Yes I think some things got flaky with creating/renaming indexes somewhere along the way with pgsql, glad you were able to work past it.

The skins were renamed to reflect the designer in the name and I removed the duplication of skins in svn, previously there were copies at /Data/skins and at /Data/Sites/1/skins, but I removed the ones under /Data/Sites/1 and now copy the skins to that location during setup if the Data/Sites/[SiteID]/skins folder does not exist.

We changed the target to 3.5 after version 2.2.7.8, it is still possible to produce a build for 2.0 though, I did it a few weeks ago for one of my customers. In VS 2008 you can just change the target to 2.0 on the projects that currently target 3.5 (I think its only the Web UI projects). Doing so will change some references in Web.config, then I just excluded any files that cause problems.

I no longer have an installation of VS 2005 so I'm going to have to give up on maintaining support for that especially since we are now targeting 3.5 and the free VS 2008 Web Developer Express can work with mojoPortal source code. I don't think VS 2005 has the ability to change the target for you, but the 2.0 settings are in comments in Web.config so you may be able to change back to them manually and just build using VS 2005 (leaving out whatever files you need to to make it build). So you can commet out the 3.5 stuff and un-comment the 2.0 stuff.

You will also need to get a copy of the 1.0 version of System.Web.Extensions.dll aka AJAX 2.0 and put it in the bin, it still exists in our _libs folder. In 3.5 that is built into the runtime.

Hope it helps,

Joe

3/12/2009 9:28:28 AM
Gravatar
Total Posts 488

Re: Trying to upgrade from revision 3399 to 4864 :)

Joe, nice to hear you too!

1. While adjusting my skins, found out the following. I have one main site and 2 folder-based ones. If I have my custom skin for site 3 only in /Data/Sites/3/skins, it does not work, I needed also to copy it to /Data/Sites/1/skins to make it work. Is that a bug or feature?

2. I shall also move the project to 3.5, I suppose. Thanks for your help!

3/12/2009 9:43:40 AM
Gravatar
Total Posts 18439

Re: Trying to upgrade from revision 3399 to 4864 :)

Hi Alexander,

If you view the source of the page for site 3 and its using skins/css from site 1 that is a bug. Let me know.

Any older custom skin does need to be updated, you should see this document for details:

http://www.mojoportal.com/important-skin-changes.aspx

Best,

Joe

3/12/2009 10:15:40 AM
Gravatar
Total Posts 488

Re: Trying to upgrade from revision 3399 to 4864 :)

In the source it calls to csshandler.ashx in site 3 only.

Having the fact that it does not work without the skin in site 1, I used SysInternals Process Monitor when loading a page from site 3 after iisreset. Here is what I got:

219676 18:13:51,1977226 w3wp.exe 5900 QueryOpen F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles\sitesettingscachedependecy.config SUCCESS CreationTime: 12.03.2009 15:03:58, LastAccessTime: 12.03.2009 15:03:58, LastWriteTime: 12.03.2009 15:03:58, ChangeTime: 12.03.2009 15:03:58, AllocationSize: 0, EndOfFile: 0, FileAttributes: A
219677 18:13:51,1982575 w3wp.exe 5900 QueryOpen F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles\sitesettingscachedependecy.config SUCCESS CreationTime: 12.03.2009 15:03:58, LastAccessTime: 12.03.2009 15:03:58, LastWriteTime: 12.03.2009 15:03:58, ChangeTime: 12.03.2009 15:03:58, AllocationSize: 0, EndOfFile: 0, FileAttributes: A
219678 18:13:51,1985657 w3wp.exe 5900 QueryOpen F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles SUCCESS CreationTime: 12.03.2009 14:58:32, LastAccessTime: 12.03.2009 18:13:48, LastWriteTime: 12.03.2009 15:14:15, ChangeTime: 12.03.2009 15:14:15, AllocationSize: 0, EndOfFile: 0, FileAttributes: D
219679 18:13:51,1988889 w3wp.exe 5900 CreateFile F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
219680 18:13:51,1989251 w3wp.exe 5900 QueryDirectory F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles\sitesettingscachedependecy.config SUCCESS Filter: sitesettingscachedependecy.config, 1: sitesettingscachedependecy.config
219681 18:13:51,1989688 w3wp.exe 5900 CloseFile F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles SUCCESS
219683 18:13:51,1992920 w3wp.exe 5900 CreateFile F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles\sitesettingscachedependecy.config SUCCESS Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
219684 18:13:51,1993280 w3wp.exe 5900 QuerySecurityFile F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles\sitesettingscachedependecy.config BUFFER OVERFLOW Information: Owner, Group, DACL
219685 18:13:51,1993442 w3wp.exe 5900 CloseFile F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles\sitesettingscachedependecy.config SUCCESS
219687 18:13:51,1996637 w3wp.exe 5900 CreateFile F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles\sitesettingscachedependecy.config SUCCESS Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
219688 18:13:51,1996926 w3wp.exe 5900 QuerySecurityFile F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles\sitesettingscachedependecy.config SUCCESS Information: Owner, Group, DACL
219689 18:13:51,1997077 w3wp.exe 5900 CloseFile F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles\sitesettingscachedependecy.config SUCCESS
219691 18:13:51,2000960 w3wp.exe 5900 CreateFile F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles SUCCESS Desired Access: Read Data/List Directory, Read Attributes, Synchronize, Disposition: Open, Options: , Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
219692 18:13:51,2003839 w3wp.exe 5900 CreateFile F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles IS DIRECTORY Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Complete If Oplocked, Attributes: n/a, ShareMode: Read, AllocationSize: n/a
219693 18:13:51,2004368 w3wp.exe 5900 NotifyChangeDirectory F:\Billing\mojoPortal SVN\Web\Data\Sites\1\systemfiles Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME, FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_LAST_WRITE, FILE_NOTIFY_CHANGE_CREATION, FILE_NOTIFY_CHANGE_SECURITY
219700 18:13:51,4523798 w3wp.exe 5900 QueryOpen F:\Billing\mojoPortal SVN\Web\Data\Sites\1\skins\starlink-manager-jsavard-subblue\style.config PATH NOT FOUND
 

So it calls to 2 files in site 1, including one from the skin!

3/12/2009 10:25:31 AM
Gravatar
Total Posts 18439

Re: Trying to upgrade from revision 3399 to 4864 :)

So it sounds like there is a bug in resolving the cachedependency location for folder sites and locating the style.config file. Probably somewhere in SiteUtils and/or StyleSheetCombiner.ascx.

Do you have time to investigate this and see if you can find the problem/solution?

3/12/2009 1:40:22 PM
Gravatar
Total Posts 488

Re: Trying to upgrade from revision 3399 to 4864 :)

Joe,

I nearly found out what is going on. When requesting /csshandler.ashx, at first CacheHelper.GetSiteSettingsFromContext() is called by UrlRewriter, and only then by CSSHandler, so CSSHandler just uses (already invalid!) SiteSettings object from HttpContext.

As far as I understood, csshandler.ashx is caled from ~/Data folder, so in case of folder-based sites it is considered to be called for the root site.

Any ideas how to solve this?

3/12/2009 1:45:17 PM
Gravatar
Total Posts 18439

Re: Trying to upgrade from revision 3399 to 4864 :)

Hi Alexander,

Can you try to add this into the UrlRewriter_BeginRequest 

add this case to make it return instead of re-writing:

|| (app.Request.Path.EndsWith("csshandler.ashx", StringComparison.InvariantCultureIgnoreCase))

Let me know if that solves it.

Thanks,

Joe

3/12/2009 3:27:52 PM
Gravatar
Total Posts 488

Re: Trying to upgrade from revision 3399 to 4864 :)

Joe,

this will not help.

Even if UrlRewriter will do nothing, CSSHandler will request CacheHelper.GetCurrentSiteSettings() which will do the same thing: call CacheHelper.GetSiteSettingsFromContext() which will call CacheHelper.GetSiteSettingsFromCache() which will not recognize folder-based site as the request is made to ~/Data/.

 

3/13/2009 6:45:54 AM
Gravatar
Total Posts 18439

Re: Trying to upgrade from revision 3399 to 4864 :)

Hi Alexander,

This sounds like it would be a problem that will only happen in the VS web server because in IIS a request for ~/Data/ will not be handled by .NET code

So if you debug using IIS you may get different results.

If we can figure out where this request for ~/Data/ is coming from we can solve it, or perhaps just return from UrlRewriter for this request so it doesn't try to get SiteSettings. So adding this to the UrlRewriter return condition may solve it.

|| (app.Request.Path.EndsWith("/Data/", StringComparison.InvariantCultureIgnoreCase))

Best,

Joe

 

3/13/2009 8:57:49 AM
Gravatar
Total Posts 488

Re: Trying to upgrade from revision 3399 to 4864 :)

Joe,

no, this problem is under IIS.

May be, I was too short in the problem description, let me describe it in a more detailed way.

Actually, there are 2 independent problems.

1. The first one is with UrlRewriter. Actually it must not do anything for requests into /Data folder, but it does. The solution you suggest is for this problem, but I suggest to replace the criteria with || (app.Request.Path.StartsWith("/Data/", StringComparison.InvariantCultureIgnoreCase)).

2. The second one is with CSSHandler, but actually with CacheHelper.GetSiteSettingsFromCache(). When request is to the /Data/ subfolder, it does not recognize folder-based subsites, thinking it's always the root site.

This problem actually does not depend on the first one: now SiteSettings are requested from CacheHelper.GetSiteSettingsFromCache() and stored in HttpContext by UrlRewriter, but if it doesn't CSSHandler will do absolutely the same.

As far as I can see, there are 2 possible solutions for the second problem: either correct CacheHelper.GetSiteSettingsFromCache() so that it can recognize the site in this case as well or modify CSSHandler so that it does not use SiteSettings. I suggest the last variant - SiteSetting are really not required there, path to the skin can be got from the request path.

You must sign in to post in the forums. This thread is closed to new posts.