Solving IIS SMTP mails stuck in Queue folder when using Gmail

It is actually quite easy to setup a local SMTP and routing through Gmail to test sending emails from your application. There are a few good posts on this that you can follow:

I however had an issue where the mails would get stuck in the Queue folder (e.g. C:\inetpub\mailroot\Queue).

I tried turning off Windows Firewall and enabling POP in Gmail but it did not help.

In the end it was because 2-factor authentication was enabled on my Gmail account. Disabling this fixed the issue for me. Here is a help document for disabling 2-factor authentication, just in case you need it:

Posted in CRM, SharePoint | Leave a comment

SPClientSideDeployment now supports deploying assemblies to GAC (On-Prem only)

While these days server-side solution looks as if it’s going out of fashion, the fact is quite a number of people are still dependent on them for various reasons. Back in the days when server-side solution was the only (practical) option, CKSDev was one of my must-have dev tools for its ability to quickly deploy assemblies to GAC and files to the Layouts folder.

CKSDev however does not work with Visual Studio 2015, and it appears the original author is no longer working on it. While there are a few posts on the web with hacks for installing it on VS 2015, some of the commands that I regularly use resulted in exceptions and did not work correctly.

Deploy assemblies to GAC with SPClientSideDeployment

The ability to quickly deploy assemblies to GAC has now been added to SPClientSideDeployment 3.2 (supported for On-Prem only). I know this is not really “client-side deployment”, and it pains me a bit, but at the end of the day what’s important is the productivity gain for developers.

What does it do?

In short, it builds the project(s), GACs the relevant output assemblies and recycle the IIS app pool of the target project.

Which assemblies will be GACed?

This command is enabled on both SharePoint and non-SharePoint projects, and the assemblies that are GACed depends on the type of the target project.

If the target is a SharePoint project, the following assemblies will be GACed:

  • The main output assembly of the target project
  • Other assemblies that are included in the SharePoint Package.package file with the Deployment Target set to Global Assembly Cache

With the Package definition below for example, the Model, ServiceLibrary and SharePointSolution1 (target project) assemblies would be GACed.

1 Package

If the target project is a non-SharePoint project, only its main output assembly would be GACed.

Which IIS app pool is recycled?

Again this depends on the type of the target project. For SharePoint projects, the command uses the OOTB Site URL project property to locate the app pool that should be recycled.

For non-SharePoint projects, the command uses the SharePoint URL project property that is added by this extension.

OK.. so how do I trigger the command?

You can trigger the command in the following ways:

  • Right-click on the code editor of a C# or VB code file and choose Deploy to GAC (SharePoint). The keyboard shortcut key for this is Alt + Q, W. This will execute the command against the active code file’s project.2 Code Editor
  • Right-click on a project and choose Deploy Assemblies to GAC (under the SharePoint group).3 Project 
  • From the Tools menu, choose SharePoint Deployment, then Deploy Assemblies to GAC. This executes the command against the solution’s start-up project. The keyboard shortcut key for this is Alt + Q, E.4 Tool Menu

Download it now!

You can download the latest version of SPClientSideDeployment from the Visual Studio Gallery.

What’s next on the roadmap?

Next on my to-do list is to add other productivity features that were found in CKSDev, including:

  • Deploy files to Layouts folder
  • Attach to IIS

I hope you find this new addition useful, and as always, I’d love to hear from you with feedback and suggestion.


Posted in SharePoint, SharePoint 2013, SPClientSideDeployment | Leave a comment

Deploy current project’s assembly to CRM with new shortcut keys in CRMQuickDeploy 2.7

A developer’s time should be spent on the logic/design of the application rather than on the repetitive motion of deploying code to the server during the dev-test-debug cycles. This is why CRMQuickDeploy includes shortcut keys that enable you to quickly deploy assemblies to CRM from Visual Studio.

Prior to this latest release however, these shortcut keys only worked on the solution’s start-up project. If there are multiple projects in your solution (e.g. Plugins, WebServices, MigrationApp, etc.), then you would need to set the start-up project to the one whose assemblies should be deployed to CRM.

Deploy current project’s assembly with new shortcut keys in CRMQuickDeploy 2.7

CRMQuickDeploy 2.7 now has shortcut keys that enable you to deploy the “current” project’s assembly to CRM. “Current project” here means the project of the code file that is currently active in Visual Studio’s code editor.

Right-clicking on the code editor of a CS or VB code file now gives you three options to compile the current project and deploy to CRM.

1 Context Menu

These actions also have associated keyboard shortcut keys as can be seen above:

  • Alt + Q, J: Deploy the current assembly to the CRM database
  • Alt + Q, K: Deploy the current assembly and their dependencies to the Bin folder
  • Alt + Q, L: Deploy the current assembly and their dependencies to the GAC

You can assign different keyboard shortcut keys to these actions via the normal mean in Visual Studio if preferred.

These actions automatically save the current file and build the project prior to deploying the assembly. See this post for more details on the steps that are performed by each action.

Download it now!

You can download the latest version of CRMQuickDeploy from the Visual Studio Gallery.

As always…

I hope you find this improvement useful, and I would love to hear from you with feedback and suggestion.

Posted in CRM, CRMQuickDeploy | Leave a comment

SPClientSideDeployment 3.1 brings support for minified JS/CSS and seamless dev-prod transition

I have just released version 3.1 of SPClientSideDeployment with added support for minified JS/CSS. You are now able to include minified files in the deployment package that the tool generates, and instruct the generated PowerShell script to use them during deployment.

Download it now!

You can download the latest version of SPClientSideDeployment from the Visual Studio Gallery.

The challenge with minified files

A typical challenge when using minified files is that you’d only want to use them in production. In dev/test you typically want to continue using the unminified version for debugging purposes. The challenge is to have a mechanism that enables you to switch to using the minified version for production without having to change the source code of the consuming pages.

Seamless dev-prod transition with SPClientSideDeployment

SPClientSideDeployment addresses this challenge by enabling you to include both minified and unminified versions in the deployment package that it generates, and then specifying which version to use when executing the PowerShell deployment script (also generated by the tool – check out this post if you are not familiar with the package generation feature of SPClientSideDeployment).

Your consuming pages will always reference the same JS/CSS file names – e.g. script.js. The content of script.js will be minified or unminified depending on the parameter you provide when executing the deployment script. SPClientSideDeployment’s Visual Studio command continues to deploy the unminified version. This allows you to continue debugging while in development, and then seamlessly transition to minified versions when the solution is promoted to higher environments.


OK, let’s have a look at an example scenario.

Let say you have a page layout, ContentPageLayout.aspx, and that page references a stylesheet, styles.css. In Visual Studio you use LESS for the stylesheet. Your DeploymentSettings.xml file may appear as follow:

		<File localPath="styles.less">
				<Destination targetFolder="Style Library"/>

		<File localPath="ContentPageLayout.aspx">
				<Destination targetFolder="_catalogs/masterpage"/>
				<!-- Metadata required for the page layout omitted -->

You have installed the Web Compiler extension, and therefore styles.css and styles.min.css are automatically generated for you each time styles.less is changed.

During development you use various methods supported by SPClientSideDeployment, e.g. auto-deploy on save, to deploy the compiled output of styles.less to SharePoint. This will always deploy the unminified version, styles.css, to SharePoint.

Publish the package and include minified files

Now you are ready to promote the solution to a higher environment. Right-click the project in the Solution Explorer and choose SharePoint \ Publish Deployment Package. The dialog below appears after you have selected a publish location.

1 Publish Dialog

Tick the “Include minified files if available” option and click OK. This option creates a “__minified” sub-folder under the selected publish location and copies the minified version of all files referenced in DeploymentSettings.xml to this sub-folder (if they are found). The unminified versions are always included in the package.

If you had selected F:\Test as the publish location, the published package would contain the following:

  • F:\Test\ContentPageLayout.aspx
  • F:\Test\styles.css
  • F:\Test\__minified\styles.min.css
  • [other files omitted]

Execute the deployment script and specify to use minified files

The published package includes a generated PowerShell file, namely DeployFiles.ps1. To execute the deployment using the minified files, include the -UseMinifiedFiles switch parameter. For example:

.\DeployFiles.ps1 -DeploymentSettingsFilePath .\DeploymentSettings.xml -SiteUrl http://myServer -AuthenticationMethod Windows -UseMinifiedFiles

Check this post for other parameters that can be specified.

When the script encounters style.less in the DeploymentSettings.xml, it will take the file F:\Test\__minified\styles.min.css and upload that to SharePoint as styles.css. If the -UseMinifiedFiles switch was not specified, the script would use the file F:\Test\styles.css instead. Since in either case the target file name will be the same, styles.css, no source code changes to the consuming page are required.

Does SPClientSideDeployment perform the minification?

No. The tool is only responsible for including the minified files in the package that it generates and allowing you to use them as part of the deployment. You must use other tools to perform the minification. You can use the Web Compiler extension to do this for example if you are working with JSX, LESS or SASS.

How does SPClientSideDeployment locate the minified files?

When the tool encounters a ‘minifiable’ file, i.e. with .js or .css extension, it looks for the minified version in the same physical location as the unminified version. The file name of the minified version must correspond to that of the unminified version, e.g. scripts.min.js for scripts.js, styles.min.css for styles.css.

What about ‘compilable’ files such as JSX, LESS or SASS?

SPClientSideDeployment supports JSX, LESS and SASS – and this includes minified compiled output. When a compilable item is encountered in the DeploymentSettings.xml, e.g. form.jsx, the tool first looks for the associated compiled output, which in this case would be form.js. The tool then look for a minified version of this output, i.e. form.min.js. Both form.js and form.min.js would then be included in the generated package and processed in the same manner as other minifiable files.

What if my solution uses a mixture of minified and unminified files?

When publishing the package, the tool simply ignores any minified file that it could not find.

When executing the deployment, if the -UseMinifiedFiles switch is specified but a minified version is not available for a minifiable file, then the tool will fallback to using the unminified version for that particular file. A warning will be generated in this case.

What if my solution uses a minified library such as jquery?

If your DeploymentSettings.xml file references minified libraries, such as jquery_1.10.2.min.js, then these are treated as ‘non-minifiable’ and they will be processed in the same way as other non-JS/CSS files. This means the tool will not look for a minified version.

In my DeploymentSetttings.xml file, do I need to explicitly reference each minifiable file?

No. You can explicitly reference the minifiable file using the File element, or use folder-based declaration using the Folder element. When processing a referenced folder, the tool will look for minified version of any minifiable file within that folder and its sub-folders.


This release of SPClientSideDeployment aims to streamline your process in developing with minifiable files and transitioning from dev to production. I hope you find it useful – and as always, would love to hear from you with feedback and suggestion.


Posted in SharePoint, SharePoint 2013, SPClientSideDeployment | Leave a comment

Setting HTML content for Content Editor Web Part by code

To set the content of a Content Editor Web Part (CEWP) by code you need to set the Content property of the ContentEditorWebPart class. There is an example of how to do this in the aforementioned MSDN link.

There is however a small trick required if you want to set the content to HTML, e.g. <b>Hello world!</b>.

The trick is to wrap the content of the XML node in a CDATA section. Below is the modified example from MSDN to do this:

// Create a new Content Editor Web Part.
ContentEditorWebPart ceWebPart = new ContentEditorWebPart();

// Create an XmlElement to hold the value of the Content property.
XmlDocument xmlDoc = new XmlDocument();
XmlElement xmlElement = xmlDoc.CreateElement("MyElement");

// Wrap content in CDATA section if it contains HTML
xmlElement.InnerText = "<![CDATA[<b>Hello world!</b>]]>";

// Set the Content property to the XmlElement.
ceWebPart.Content = xmlElement;
Posted in SharePoint | Leave a comment

SPClientSideDeployment 3.0 adds auto-deploy on save option and support for compilable JS and CSS

I have just released version 3.0 of SPClientSideDeployment with two major enhancements:

  • Auto-deploy on save: when this option is enabled, files will automatically be deployed to SharePoint each time you save them
  • Support for compilable JavaScript and CSS: the tool detects if the file is TypeScript, JSX, LESS or SASS, and if so deploys the compiled output to SharePoint

Download it now!

You can download the latest version of SPClientSideDeployment from the Visual Studio Gallery.

Auto-deploy on save

When this option is enabled, files configured for deployment in DeploymentSettings.xml will be automatically deployed to SharePoint each time they are saved.

To enable this option go to Tools \ Options \ SPClientSideDeployment and set Automatically Deploy on Save to true.

1 Option Menu

Note that this option does not report any error if the file you are saving is not defined in DeploymentSettings.xml. If a file is not being deployed on save as you had expected, then check if the file is correctly configured in DeploymentSettings.xml by explicitly triggering a deployment for the file (i.e. right-click then Deploy to SharePoint).

Support for compilable JavaScript and CSS

You can now specify TypeScript, JSX, LESS and SASS items in DeploymentSettings.xml for deployment. When the tool encounters one of these file types, it will look for and deploy the corresponding compiled output file instead of the actual source file.

For example, if the following was specified in DeploymentSettings.xml:

<File localPath="Scripts.ts">
		<Destination targetFolder="Style Library" />

then the tool will look for the file Scripts.js and deploy that to the Style Library. 

“Compilable” items are also supported when the Folder element is used in DeploymentSettings.xml. When processing files in the specified folder, the tool would look for and deploy the corresponding compiled outputs for any detected compilable items. Non-compilable items are processed as normal.

How compiled outputs are inferred

The tool always looks for the compiled output in the same physical location as the source file. The file name of the compiled output is inferred from the file name of the source file.

  • TypeScript source file: example.ts   –   compiled output: example.js
  • JSX source file: example.jsx   –   compiled output: example.js
  • LESS source file: example.less   –   compiled output: example.css
  • SASS source file: example.scss   –   compiled output: example.css

Automatic compilation of compilable JavaScript and CSS

The tool only looks for and deploys the compiled outputs of compilable items. It does not perform any compilation. The tool works best when automatic compilation of these items are enabled in Visual Studio.

For TypeScript, automatic compilation is supported in Visual Studio 2015. By default this is only available for ASP.NET Web Application projects. See this post for enabling it on other project types.

For JSX, LESS and SASS, you can use the Web Compiler extension to enable this.

SPClientSideDeployment’s option to automatically deploy on save works nicely with automatic compilation. If you have enabled this option, then the tool will monitor and automatically deploy the compiled outputs after the compilation has finished.

How compilable items are treated when publishing deployment package

SPClientSideDeployment has a feature that allows you to publish your project as a package for deployment. The package includes a PowerShell script that you can use to deploy the files to a target SharePoint instance. I encourage you to read more about this feature here if you are not already familiar with it.

Support for compilable items has also been added to this feature. When publishing a package, if a compilable item is detected, then only its compiled output would be included in the package. The generated PowerShell script would correctly deploy the compiled outputs to the target SharePoint instance.

Note that the PowerShell script has been updated to include this support. Therefore, if you are updating an existing project to take advantage of this feature, then you’d need to republish the package to regenerate the PowerShell script.

Support for minified version of compiled outputs

Currently there are no supports for minified version of the compiled outputs. This will be added in the next version.


This release aims to further streamline your dev-deploy-test-repeat process and enables you to extend this streamlined approach to compilable JavaScript and CSS. I hope you find the new features useful – and as always, would love to hear from you with feedback and suggestion.


Posted in SharePoint, SPClientSideDeployment | Leave a comment