Microsoft.VisualStudio.ExtensionManager.NestedExtensionInstallException

In my case the the selected instalation path for this extenstion was as following

C:\Documents and Settings\shaukat.mahmood\Local Settings\Application Data\Microsoft\VisualStudio\10.0\Extensions\Microsoft .............................................. and so on

However after doing some RnD on this topic I have devised a solution as following,

Open devenv.pkgdef located at path <VisualStudioRootFolder>\Common7\IDE\devenv.pkgdef

The file can be opend in Visual Studio IDE, or using any text editor like notepad.

This is path of Master PkgDef file that defines the well known locations for VSIX extensions.

Now modify the Value for "UserExtensionsRootFolder" as folloowing

"UserExtensionsRootFolder" = "$RootFolder$\Common7\IDE\Extensions"

This will direct VSIX extension installer to install the extension under root folder of visual studio instalation.

After making this change your extension will be installed successfuly, but tehre is one issue, you will lose all the existing extensions taht are installed under ...Document and Setting \ Applictaion Data ....... folder, to keep these extensions working append $AppDataLocalFolder$\Extensions; value to PkgDefSearchPath key in devenv.pkgdef file.

And finaly you devenv.pkgdef should look as following

[$Initialization$]

"ApplicationExtensionsFolder" = "$RootFolder$\Common7\IDE\Extensions"

"PkgDefSearchPath" = "$AppDataLocalFolder$\Extensions;$ApplicationExtensionsFolder$;$RootFolder$\Common7\IDE\CommonExtensions;$RootFolder$\Common7\IDE\devenv.admin.pkgdef;"

"UserExtensionsRootFolder" = "$RootFolder$\Common7\IDE\Extensions"

"RegistryRoot" = "Software\Microsoft\VisualStudio\10.0"


Published: 10/18/2011 | 0  Comments | 0  Links to this post

SharePoint Built In Fields

 

You can use SPBuiltInFieldId, this will get you a reference to the correct field using its GUID rather than its name. The full list of built in fields is in the SPBuiltInFieldId documentation.

There are a couple of problems with the fields to watch out for:

  • If you want to get the account who created an item, use the field SPBuiltInFieldId.Author not SPBuiltInFields.Created_x0020_By
  • If you want to get the account that last modified an item, use SPBuiltInFieldId.Editor not SPBuiltInFieldId.Modified_x0020_By

I’m not sure when SPBuiltInFields.Created_x0020_By would work but in my experience on a regular list, it’s always empty so I used SPBuiltInFieldId.Author instead.

So for example to get the account that created a list item as an SPUser object (so you can get the name or their email address) use code like this:

Guid fieldName = SPBuiltInFieldId.Author;
SPUser _result = null;
           try
           {
               SPSecurity.RunWithElevatedPrivileges(delegate()
               {
                   SPFieldUser _field = item.Fields[fieldName] as SPFieldUser;
                   if (_field != null)
                   {
                       SPFieldUserValue _value = _field.GetFieldValue(item[fieldName].ToString()) as SPFieldUserValue;
                       if (_value != null)
                           _result = _value.User;
                   }
               });
           }
           catch (SPException dex)
           {
               ExceptionHandling.LogError(dex);
           }


Published: 10/17/2011 | 0  Comments | 0  Links to this post