Here is a quick guide for PowerShell tips in SharePoint 2010:
http://www.powergui.org/servlet/KbServlet/download/2812-102-4534/SharePoint2010PowerShell.pdf
And this Technet article gives a complete mapping of STSADM commands with PowerShell Commands:
http://technet.microsoft.com/en-us/library/ff621081.aspx
Tuesday, June 22, 2010
SharePoint 2010 DataSheet View - The list cannot be displayed in DataSheet view for one or more of the following reasons
After Installing Office 2010 if you try to use DatasheetView option in SharePoint 2010 List, you are thrown with a error:
The list cannot be displayed in DataSheet view for one or more of the following reasons: blah blah.....
For some reason Access is still relying on AccessDatabaseEngine which is a 2007 Office System Driver: Data Connectivity Components. Microsoft doesn't say much about this component as a prerequisite either.
Download and install this component and it will fix your error.
http://www.microsoft.com/downloads/details.aspx?familyid=7554F536-8C28-4598-9B72-EF94E038C891&displaylang=en
The list cannot be displayed in DataSheet view for one or more of the following reasons: blah blah.....
For some reason Access is still relying on AccessDatabaseEngine which is a 2007 Office System Driver: Data Connectivity Components. Microsoft doesn't say much about this component as a prerequisite either.
Download and install this component and it will fix your error.
http://www.microsoft.com/downloads/details.aspx?familyid=7554F536-8C28-4598-9B72-EF94E038C891&displaylang=en
Wednesday, May 5, 2010
Web Platform Installer could not start
The error when running Web Platform Installer doesn't say much. Just make sure you have downloaded the right bit version of this software and the error will go away.
x86 version: http://go.microsoft.com/fwlink/?LinkId=146053
x64 version: http://go.microsoft.com/fwlink/?LinkId=146055
x86 version: http://go.microsoft.com/fwlink/?LinkId=146053
x64 version: http://go.microsoft.com/fwlink/?LinkId=146055
Tuesday, February 2, 2010
Update Item properties after document is checked in without checking out again
There might be cases when you would want to update an Item's/Document's property after it has been checked in. You would not want to checkout the item again as you want to maintain the version number that was generated by UI checkin. For example in my case I wanted to update a field when the document was published with major version and approved by approval workflow.
You could not do in ItemUpdating because some fo the fields are not exposed in Item.AfterProperties collection and also it would result in an infinite loop.
Option left is ItemUpdated event, but in this even the document is already being checked in and published with major version. So how can you do it without checking out the document again. This is what you can do:
SPSecurity.RunWithElevatedPrivileges(delegate
{
if (file.Item.ModerationInformation.Status == SPModerationStatusType.Approved)
{
file.Item["DocumentNumber"] = "XYZ";
file.Item.SystemUpdate(false);
}
}
Doing Item.SystemUpdate(false) does not increments the version number and does not update modified date or modified by and running under elevated privilegs it does not look to check out the document.
Hope it will be helpful to some one.
You could not do in ItemUpdating because some fo the fields are not exposed in Item.AfterProperties collection and also it would result in an infinite loop.
Option left is ItemUpdated event, but in this even the document is already being checked in and published with major version. So how can you do it without checking out the document again. This is what you can do:
SPSecurity.RunWithElevatedPrivileges(delegate
{
if (file.Item.ModerationInformation.Status == SPModerationStatusType.Approved)
{
file.Item["DocumentNumber"] = "XYZ";
file.Item.SystemUpdate(false);
}
}
Doing Item.SystemUpdate(false) does not increments the version number and does not update modified date or modified by and running under elevated privilegs it does not look to check out the document.
Hope it will be helpful to some one.
Labels:
Check Out,
ItemUpdated,
SystemUpdate,
VersionNumber
Thursday, December 31, 2009
The form template associated with this form was moved or cannot be accessed. The form template on your computer has the same form ID as the template
Many of you might have come across this shitty error while developing custom InfoPath forms and deploying them to SharePoint. I have spent ages in playing with InfoPath in troubleshooting this error and many others. I will explain quick fix for this error for the moment.
"The form template associated with this form was moved or cannot be accessed. The form template on your computer has the same form ID as the template associated with the form, but it is from a different location."
Now, lot of times you would deploy InfoPath form to SharePoint document library or content type using the Publish wizard feature. In my case I had to deploy my custom DIP (Document Information Panel) to a custom content type. Now I had written a feature receiver for content type which assigns my custom DIP to the content type once the content type is created by feature. Since I had developed InfoPath form on my dev machine and deploying it to dev SP site it complains about Form ID as in above error. This error means that when you developed a form on your machine and saved it, it has added a publishURL attribute as the saved location. Now even if you publish this form to SharePoint, the publish URL remains the same. So the buggy publishing wizard doesn't update this attribute. So when my document with custom DIP is opened it tries to fetch the InfoPath form from SharePoint location where publishedURL is a path on my machine where the form was developed and saved and it gets confused when trying to create it from SharePoint location.
So we know the fix now its easy : Remove the publishURL from the form isn't it?
YES and NO, the solution is easy but actually fixing it is not. To change this URL its pain in right place!!! If you use InfoPath designer option of "Save as source files" and then change the manifest.xsf and then save it again using InfoPath designer then the publishURL attribute is repopulated. So you have to do this removal outside of InfoPath.
Below are the steps to remove publishURL attribute from the form:
"The form template associated with this form was moved or cannot be accessed. The form template on your computer has the same form ID as the template associated with the form, but it is from a different location."
Now, lot of times you would deploy InfoPath form to SharePoint document library or content type using the Publish wizard feature. In my case I had to deploy my custom DIP (Document Information Panel) to a custom content type. Now I had written a feature receiver for content type which assigns my custom DIP to the content type once the content type is created by feature. Since I had developed InfoPath form on my dev machine and deploying it to dev SP site it complains about Form ID as in above error. This error means that when you developed a form on your machine and saved it, it has added a publishURL attribute as the saved location. Now even if you publish this form to SharePoint, the publish URL remains the same. So the buggy publishing wizard doesn't update this attribute. So when my document with custom DIP is opened it tries to fetch the InfoPath form from SharePoint location where publishedURL is a path on my machine where the form was developed and saved and it gets confused when trying to create it from SharePoint location.
So we know the fix now its easy : Remove the publishURL from the form isn't it?
YES and NO, the solution is easy but actually fixing it is not. To change this URL its pain in right place!!! If you use InfoPath designer option of "Save as source files" and then change the manifest.xsf and then save it again using InfoPath designer then the publishURL attribute is repopulated. So you have to do this removal outside of InfoPath.
Below are the steps to remove publishURL attribute from the form:
- Rename .XSN form to .CAB
- Extract all files from CAB file to a temporary folder.
- Open manifest.xsf file using Visual Studio or in a notepad.
- On the very first node (root node), remove name and publishURL attributes. Just get rid of those devils!!!.
- Now you need to repackage those files into a cab file - So we will use makecab.exe tool.
- Create text file in same location where your folder with extracted files are. Name it something like makefilename.txt. This file is like .ddf file if you have played with generating .wsp packages. Anyways, lets not get distracted, so what will go in this file? Well just copy following script and replace the names:
- ;************************************************************
; MSDN Sample Source Code MakeCAB Directive File
;************************************************************
.OPTION EXPLICIT
.Set CabinetNameTemplate=Replacefilename.XSN
;*****************************************************************
; Change DiskDirectoryTemplate to where you want the CAB/XSN saved.
;*****************************************************************
;********Replace this path with your where you want to create the cab file********
.set DiskDirectoryTemplate="C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates"
.Set Cabinet=on
.Set Compress=on
;*************************************************
; List Every File You Want Added To The CAB (XSN)
;*************************************************
"C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\AO.xsl"
"C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\Context.xml"
"C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\Context.xsd"
"C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\dc.xsd"
"C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\dcmitype.xsd"
"C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\dcterms.xsd"
"C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\GetUserProfileByName1.xml"
"C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\GetUserProfileByName3.xsd"
"C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\GetUserProfileByName4.xsd"
;*****************
; End Of The File
;***************** - You will notice in your folder you have either more or less files to be packaged, if they are less then its easy to put them manually, but if the form is higly customised like mine was I had like 20 files to be packaged. You can get all the filenames in a text file easily by running DOS command from the folder location as mentioned below:
- dir "." /b >>fileListing.txt
- Now you can copy the filenames form filelisting.txt and place them in above makefilename.txt file with paths appended in front
- Now run makecab utility as: makecab /f C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\makefilename.txt
- You can find your new xsn file at the mentioned location.
Thursday, October 22, 2009
SharePoint 2010 Secrets
Any one interested in knowing about what to expect from SP 2010. Read here: http://www.sharepoint2010beta.com/SharePoint2010SecretsIssue1.pdf
And look for more sneak peek videos here:
http://sharepoint2010.microsoft.com/Pages/default.aspx
And look for more sneak peek videos here:
http://sharepoint2010.microsoft.com/Pages/default.aspx
Thursday, September 10, 2009
Error while trying to run project: Unable to start debugging ... The components for the 64-bit debugger are not registered
I had installed Visual Studio 2008 64 bit version on Windows Server 2008 and after install it complains about this error. Tried the specifed solution but remote debugging components are not a part of the features list in install setup. So digged down the install cd and found
"Remote Debugger/x64" folder. There we go found the installer about which Visual Studio was complaining. Error is gone! And I can hit F5 in my project without any errors :-).
Thought I will post this if someone might end up in same situation and so don't have to waste time digging around for solutions.
"Remote Debugger/x64" folder. There we go found the installer about which Visual Studio was complaining. Error is gone! And I can hit F5 in my project without any errors :-).
Thought I will post this if someone might end up in same situation and so don't have to waste time digging around for solutions.
Subscribe to:
Posts (Atom)
