Many of our folks in the field rely on SharePoint Farm Version number information in Central Administration to compare the patch level between servers. While this number is showing the latest SharePoint Foundation, it doesn’t always mean that you have a completely patched SharePoint farm. The reason, because Microsoft releases many different type of patches:
Cummulative updates (CU) Server packages (Uber packages) Public updates (PU) Stefan Gossner wrote an excellent blog about SharePoint patch terminology and the impact your farm patch level in “SharePoint Patching Demystified” .
English Previously in the part-1 and part-2, we discuss the problem to create installation package in a complex project. We choose to use Nuget package instead of creating MSI, as Nuget implements OPC and very close to developer activities. Moreover it still serve our purpose to create versioned package, where version number of the installation package is embedded in the package itself. In this part, I continue to provide an example to package SharePoint Solution (WSP) into an installation package.
Yes, starting from this month bi-monthly SharePoint CU will become a history. From July 2014 Microsoft will release CU every month - yes EVERY MONTH!. So forget about bi-monthly. With this change policy, we expect that Microsoft will be able to address problem more quickly. The drawback, we know there were incidents in the past that some patches / CU were not going well. Microsoft subsequently released updated patch after releasing the patch / CU.
English We continue our discussion to create installation package for our complex project. To remind you, a complex project is a software development project that delivers many component in the BOM (SharePoint WSP, scripts, batch files, etc.) See part-1 here. Defining Package Format As the title suggest, our package format is Nuget. Nuget is the package manager for the Microsoft development platform - so we expect that every developer is familiar with the tool.
English It is rare that in real-life project that we only deliver 1 SharePoint Solution using WSP in the installation package of our solution. Even in very simple case, the installation package must contain at least Release Notes, Installation Guide which is not part of WSP. In more complex case, the installation package must also contains scripts, batch file, reporting services files, windows service installation and many more. Yes, we can create custom MSI and put all of those items together in the installation package as our ancient did.