Gonna go ahead and apologize if someone has written something like this already. I did some googling, pinged JammyKam (which means if he doesn’t know about it, it doesn’t exist), and alas, nothing.
During a new site setup, I was clocking along, minding my own business, when I got a nasty error about some assembly load:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
Well that sucks. How about a stack trace!
[ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.] System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) +0 System.Reflection.Assembly.GetTypes() +113 RazorGenerator.Mvc.PrecompiledViewAssembly.GetTypeMappings() +24 Sitecore.Mvc.ViewEngineRegistration.PrecompiledViewAssemblyBuilder(Assembly assembly, Boolean usePhysicalViewsIfNewer) +114 System.Linq.WhereSelectEnumerableIterator`2.MoveNext() +223 System.Linq.Buffer`1..ctor(IEnumerable`1 source) +162 System.Linq.Enumerable.ToArray(IEnumerable`1 source) +106 Sitecore.Mvc.ViewEngineRegistration.RegisterViewEngine() +373 Sitecore.Mvc.Pipelines.Loader.InitializeRoutes.RegisterRazorViewEngine() +296 Sitecore.Mvc.Pipelines.Loader.InitializeRoutes.RegisterRoutes(RouteCollection routes, PipelineArgs args) +414 Sitecore.Mvc.Pipelines.Loader.InitializeRoutes.Process(PipelineArgs args) +109 (Object , Object ) +74 Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args) +479 Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain) +22 Sitecore.Nexus.Web.HttpModule.Application_Start() +288 Sitecore.Nexus.Web.HttpModule.Init(HttpApplication app) +673 System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo handlers) +583 System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo handlers, IntPtr appContext, HttpContext context) +169 System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +396 System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +333
Not so much on the helpful front. I’d love to be able to inject some error handling in Sitecore’s pipelines, but that’s not so easy. After some screwing around, I finally realized I had used a 9.0 version of the Sitecore.MVC.dll, rather than the Sitecore 8.2 update 6 version. Nuget fail. Wonk wonk!
I know there had been circulating an excel sheet that had the latest assembly versions in it, which was super helpful if you knew the version you had and wanted to check it. If you wanted to verify all the assemblies in an install…you’re gonna be in for a world of hurt.
With that in mind, I figured it would be nice to be able to see at a glance all the assemblies in your bin, and how they compare to a fresh install of that version.
Enter the Sitecore Assembly Version Checker (AVC). It comes in two flavors: Web and Powershell. For the web version, you just drop the aspx in the sitecore/admin folder. For the powershell version, you unzip the ps1 and the manifest in the sitecore admin folder. Could you run these directly from the bin folder? Sure. Why though?
What’s it do?
It’s pretty straight forward. I built manifests (or better yet, I wrote an app that builds a manifest) of all the dll files in the Sitecore packages directly off SDN. This gives a vanilla baseline that you can use to run a File Version compare against to see which are out of date or the incorrect version. That’s about it. This was a feel-good project for me, so download it and feel good.
For the ASPX, you can invoke it by hitting the following URL: /sitecore/admin/AssemblyVersionChecker.aspx?v=VERSION
You can use the following Versions with AVC: 8.1.0 – 8.1.3, 8.2.0 – 8.2.6, 9.0.0 and 9.0.1. So if you wanted to check your install against Sitecore 8.2 Update 4, you’d run http://SITE/sitecore/admin/AssemblyVersionChecker.aspx?v=8.2.4
A quick screen grab of the output from the ASPX:
For the PS version, invoke it via command line: .\AssemblyVersionChecker.ps1 VERSION
Again, if you wanted to check your install against the 8.2 Update 4 manifest, you’d run .\AssemblyVersionChecker.ps1 8.2.4 from the bin folder at the PS Prompt.
(The same versions apply for both PS and ASPX)
It looks like this when it runs:
Here’s the link to the aspx zip: http://www.rockpapersitecore.com/wp-content/uploads/2018/AssemblyVersionChecker.zip
Here’s the link to the Powershell: http://www.rockpapersitecore.com/wp-content/uploads/2018/AssemblyVersionChecker_Powershell.zip
This looks similar to a feature added into TDS Classic a while back, where you can actually prevent your builds from deploying an incorrect version of a DLL to your site.
This would’ve prevented your site from breaking in the first place. 🙂
Also similar to the auditing of versions… I created a module for guessing the NuGet package versions to use, based on the DLLs in a Sitecore webroot. (there are subtle differences in some DLL names/versions to the NuGet package names/versions that contain them).
Good work though….
Agree that TDS is a great solution. I was trying to come at this from a more agnostic approach, since not everyone is running with TDS (even though they should be!)…
I like it. It will solve a deployment issue I’m currently working through. I need a way of determining the deployed version of xConnect.
In the PS version, I’d include an optional param where you can specify the bin path. xConnect is in a different location from Sitecore’s webroot.
Good call. I’ve updated the code to allow the passing in of the bin path. If you omit, it defaults to “..\..\bin” like it did originally.
One more question – when Sitecore 9.0.2 comes out, how does the manifest get updated? Would you consider hosting a manifest file on a public Github that you (or somebody via PR) could keep up-to-date?
I really like it, but it’s missing 8.2 U7.
Can you please add it?