In my InfoPath page, I have placed a file attachment control on it for users to attach files with the InfoPath page they are filling out.

The file attachment control seemed to have a built-in limit of 4MB as to the maximum file size the users can upload.  I want to increase it to 25 MB.

I found this post (http://www.k2underground.com/blogs/fromthebench/archive/2008/03/10/infopath-file-attachment-size-limit.aspx) which told me that I had to just increase the httpRuntime maxRequestLength to achieve this, but my Web.Config had this already set for 50 MB. That article is probably for an older version of SharePoint.

To achieve it, I performed the following actions:

Go to Start à Admin tools à Central Admin à Application Management à Under Info-path forms services go to configure info-path forms services à Change the Form Session State to have a maximum size of 25000 KB.

By default, all my site-collections were using the en-US locale.  This can be seen in site actions --> site settings --> regional settings.  The short date-time format for this locale is "M/d/yyyy" (i.e. 10/24/2008).

I was given the task of trying to figure out how to change the short date-time format for all my site collections to "yyyy-MM-dd" (i.e. 2008-10-24).

My first instinct was to see if there was any settings within SharePoint itself in the Central Admin or Site Settings which allowed me to do this.  No luck.

Next, I figured that SharePoint must get the regional & locale settings from the Regional and Language Options on the server (start --> control panel --> Regional and Language Options), so I went and changed the Short date format here.  FYI, this just sets the values in the registry under HKEY_USERS\.DEFAULT\Control Panel\International.  Again, no luck.

At this point, I figured I would turn to code and use the CultureAndRegionInfoBuilder class which is new for .NET 2.0. (http://msdn.microsoft.com/en-us/library/system.globalization.cultureandregioninfobuilder(VS.80).aspx).  Here is the code I tried to run on my server (as an administrator):

            try
            {
                CultureAndRegionInfoBuilder.Unregister("en-US");
            }
            catch (System.ArgumentException)
            {
                //The specified custom culture 'en-US' was not found.
                //ignore
            }
            catch (Exception)
            {
                throw;
            }

            CultureAndRegionInfoBuilder carib = new CultureAndRegionInfoBuilder("en-US", CultureAndRegionModifiers.Replacement);

            carib.GregorianDateTimeFormat.ShortDatePattern = "yyyy-M-d";

            carib.Register();

 Again, this didn't seem to work.

Turns out that SharePoint for some reason uses the default short date for the locale it is set at.  So even though I was changing the ShortDatePattern, it wasn't looking at it.

 After a bit of research I found this post  http://sharepointex.blogspot.com/2007/09/how-to-modify-date-format-in-sharepoint.html which gave me the information I needed.

 From the help given in this post, what I decided to do was to try to find a locale/regional setting that had the short date I wanted (fr-CA seems to work) and then use the CultrueAndRegionInfoBuilder to copy all the locale settings from en-US to it.  After this, I changed the locale for all the site collections and their sub-sites to use this customized fr-CA culture which is basically en-US using fr-CA's short date format.  I deployed it as a feature, the main functiona for my code is below:

         public void ChangeLocale(SPSite site)

        {

            try

            {

                CultureAndRegionInfoBuilder.Unregister("fr-CA");

            }

            catch (System.ArgumentException)

            {

                //The specified custom culture 'fr-CA' was not found.

                //ignore

            }

            catch (Exception)

            {

                throw;

            }

            CultureAndRegionInfoBuilder carib = new CultureAndRegionInfoBuilder("fr-CA", CultureAndRegionModifiers.Replacement);

            carib.LoadDataFromCultureInfo(new CultureInfo("en-US"));

            carib.LoadDataFromRegionInfo(new RegionInfo("US"));

            carib.GregorianDateTimeFormat.ShortDatePattern = "yyyy-M-d";

            carib.GregorianDateTimeFormat.DateSeparator = "-";

            carib.Register();

            CultureInfo ci = new CultureInfo("fr-CA");

            using (site)

            {

                for (int i = 0; i < site.AllWebs.Count; i++)

                {

                    using (SPWeb web = site.AllWebs[i])

                    {

                        web.Locale = ci;

                        web.Update();

                    }

                }

            }

        }

        public void RemoveLocale(SPSite site)

        {

            try

            {

                CultureAndRegionInfoBuilder.Unregister("fr-CA");

            }

            catch (System.ArgumentException)

            {

                //The specified custom culture 'fr-CA' was not found.

                //ignore

            }

            catch (Exception)

            {

                throw;

            }

            CultureInfo ci = new CultureInfo("en-US");

            using (site)

            {

                for (int i = 0; i < site.AllWebs.Count; i++)

                {

                    using (SPWeb web = site.AllWebs[i])

                    {

                        web.Locale = ci;

                        web.Update();

                    }

                }

            }

        }

Note: if you are in a farm environment, this feature needs to be locally activated on all servers so that the custom carib culture can take effect server wide.

I recently was given the task of creating an entire Internet facing site using WSS (Windows SharePoint Services) 3.0.  I created web part pages everywhere so that the content manager could login and customize the content on each page.  The problem that I was having was that this site had very high web traffic so I needed to ensure that the pages loaded up very quickly.  I also needed to ensure that the pages in design mode and unpublished pages were not cached.  Unlike MOSS, WSS didn't have the ability to turn on output caching on directly for different versions of the page.  With a little fiddling around and some relection of the assemblies, I was able to get caching working on my web part pages.  Enjoy!

Step 1:

Modify the Page attribute of

a) default.aspx in the root of your web site and
b) all of the web part page layouts (Local_drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\TEMPLATE\1033\STS\DOCTEMP\SMARTPGS\) to inherit from a custom assembly:

 <%@ Page language="C#" MasterPageFile="~masterurl/custom.master" Inherits="MyAssembly.MyCustomWebPartPage,MyAssembly,Version=1.0.0.0,
Culture=neutral,PublicKeyToken=ec04d212dae41cff" %>

Step 2:

Ensure that this assembly is listed as a safe-control in your web.config and is signed with a strong-key:

Web.Config: 

<SafeControls>
   <SafeControl Assembly="MyAssembly, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=ec04d212dae41cff"
    Namespace="MyAssembly.MyCustomWebPartPage" TypeName="*" />
</SafeControls>

Step 3:

Inherit from (Microsoft.SharePoint.WebPartPages.WebPartPage) and use the following code in the class:

    public class MyCustomWebPartPage : Microsoft.SharePoint.WebPartPages.WebPartPage

    {

        protected override void OnInit(EventArgs e)

        {

            bool cacheEnabled = bool.Parse(GetAppSetting("WebPageCacheEnabled", "False"));

            //this needs to be set in order to prevent WSS from setting cache headers

            if (cacheEnabled)

                SPContext.Current.UseDefaultCachePolicy = false;

            base.OnInit(e);

            if (cacheEnabled)

                SetContextProperties();

        }

        private static string GetAppSetting(string key, string defaultValue)

        {

            string setting = defaultValue;

            if (System.Configuration.ConfigurationManager.AppSettings[key] != null)

            {

                setting = System.Configuration.ConfigurationManager.AppSettings[key].ToString();

            }

            return setting;

        }

        internal static void SetContextProperties()

        {

            SPControlMode display;

            if (string.IsNullOrEmpty(HttpContext.Current.Items["ContextPropertiesSet"] as string))

            {

                HttpContext.Current.Items["ContextPropertiesSet"] = "true";

                display = SPControlMode.Display;

                if (HttpContext.Current.Request.Form["MSOLayout_InDesignMode"] != "1")

                {

                    string str = HttpContext.Current.Request.QueryString["DisplayMode"];

                    if (!string.IsNullOrEmpty(str) && (string.Compare(str, "DESIGN", StringComparison.OrdinalIgnoreCase) == 0))

                        display = SPControlMode.Edit;

                }

                else

                    display = SPControlMode.Edit;

                //Only cache if the file is published (i.e. not in draft or checked out mode) and the page is not in edit mode (determined above)

                if (((SPContext.Current.FileLevel == SPFileLevel.Published)) && (display == SPControlMode.Display))

                {

                    //Default cache timeout to 5 min if not set

                    double cacheTimeOutSeconds = double.Parse(GetAppSetting("WebPageCacheTimeoutSeconds", "300"));

                    HttpContext.Current.Response.Cache.SetExpires(DateTime.Now.AddSeconds(cacheTimeOutSeconds));

                    HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.Server);

                    HttpContext.Current.Response.Cache.SetValidUntilExpires(true);

                }

            }

        }

    }

 There you have it!  A speedy loading web page completely coming out of cache!