Sitecore 8 Install Error: “The name you entered is not unique.”
I was working on my business partner’s computer to help him fix errors with his Sitecore instance for his certification class. He experienced multiple issues with the Sitecore 8 installer on Windows 8 and we went the manual route of deleting Sitecore to install clean and start from scratch. In the process, we:
- Deleted the IIS website instance in the IIS Manager
- Deleted the databases used by the instance
- Deleted the root folder in the filesystem
After launching the installer again, it kept returning the error “The name you entered is not unique.” when naming the Sitecore instance to one previously used. After checking the IIS metabase and a few other typical locations, couldn’t figure out where the Sitecore installer was finding the name since we deleted everything manually. It turns out that the Sitecore executable installer creates a registry entry under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sitecore CMS which is used to display information in Windows Programs and Features. This registry key is also checked during the installation process and if a child key with the same name as the one being installed is found, the above error message is shown.
To fix this:
- Start -> Run (or Windows Key + R)
- Type regedit
- Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sitecore CMS.
- Delete the registry keys containing the information about the previously installed instance.
NOTE: You’ll need to relaunch the installer as it apparently caches the key information.
Visual Studio 2013 package did not load correctly
Today I loaded up Visual Studio to continue work on a project and created by a random bunch of errors. All were complaints that various packages could not be loaded. The one I captured was:
[alert color=”gray”]The ‘JavascriptWebExtensionsPackage’ did not load correctly.’ The problem may have been caused by a configuration change or by the installation of another extension.[/alert]
I had just installed SyncFusion’s Essential Studio which apparently screwed something up. I tried doing a repair on Visual Studio which unfortunately did not work.
I was able to fix it by following these steps:
- Close Visual Studio Open the *Users*\AppData\Local\Microsoft\VisualStudio\12.0\ folder
- Rename the ComponentModelCache folder
- Restart Visual Studio.
Visual Studio should now rebuild the cache and no longer display the error messages.
ASP.NET MVC Model Generator
In making the switch to ASP.NET MVC, I’ve moved away from using my old Data Access Layer that I’ve used for years and have opted to use Dapper as my ORM of choice in the quest for optimal performance. My DAL was actually pretty optimized for WinForms and WebForms (using straight SQL Queries and SQL parameters) but mapping it to models wasn’t something I had in mind when I created it. I’m finding Dapper takes some getting used too but it is still pretty fast. The downside is that writing the code for Models to wire it up is proving to be a little tedious.
To that effect, I wrote a little application that has helped me generate the models from a database dynamically. It’s in it’s infancy stages and something I cobbled together in less than 8 hours but it works. I’ll add more features too as time goes on if there’s enough interest or to satisfy my own needs. In the meantime, I’m open sourcing the project as it may help others and I’d love to see it become something grander if others are willing to contribute to it. There’s also some useful bits of code that others may find useful to reference like dynamically reading fields from a database, pluralization/singularization of words, amongst others.
You can find the repository on Github: https://github.com/gregvarghese/MVCModelGenerator
How to Reset Sitecore 7.1 & Sitecore 7.5 Forgotten/Lost Admin Password
In working on implementing a Sitecore site into an existing code base inherited from another vendor, I discovered that the admin password had been modified and the vendor would not share it. Not being able to login to the admin section of Sitecore was not ideal to say the least. After scouring the web, most articles contained instructions on how to reset the password, but almost all of them applied to Sitecore 6 and below. For Sitecore 7 and above, most articles were not applicable as they introduced the PasswordSalt field into the database which Sitecore uses to hash the password.
If you’ve run into a similar situation, or you’ve forgotten or lost your admin account password, getting access back to everything is pretty simple. Load SQL Management (or your favorite SQL editor) and execute this query against your Core database:
UPDATE dbo.aspnet_Membership SET [Password]=’qOvF8m8F2IcWMvfOBjJYHmfLABc=’, [PasswordSalt]=’OM5gu45RQuJ76itRvkSPFw==’, [IsApproved] = ‘1’, [IsLockedOut] = ‘0’ WHERE UserId IN (SELECT UserId FROM dbo.aspnet_Users WHERE UserName = ‘sitecore\Admin’)
This will now reset the default admin password to ‘b’ so that you may login to the Sitecore desktop. Happy editing!
Reading JSON through JQuery from Cross Domain ASP.NET Web Service
Recently I had an issue with JQuery and accessing JSON from a cross domain ASP.NET Web Service. After much googling, I stumbled upon many articles that provided no fix that would solve the issue.
Every sample I found was some derivative of the following code:
$.ajax({ type: 'POST', dataType: 'jsonp', contentType: "application/json; charset=utf-8", , url: 'http://www.domain.com/webservice.asmx/function', data: '{}', success: function (response) {} });
Nearly every post pointing out that the contentType argument was the issue but it still didn’t work when I included it. There were posts that said you can’t use GET and had to use POST. There might be valid security issues with not using GET but that’s another topic of discussion. in the case of an open web service where you’re providing raw data to be consumed, a GET should suffice just fine.
To support GET, you need to add the following attribute tags to your asmx.cs:
[sourcecode language=”csharp”][WebMethod(), ScriptMethod(UseHttpGet = true, ResponseFormat = ResponseFormat.Json)][/sourcecode]
This will cause ASP.NET to automatically serialize the returned data to JSON without requiring you to do it manually in code. There are no issues when making the call locally either. The second you go cross domain, the call fails.
A few articles mention JSONP (JSON with Padding) which is supposed to provide a workaround for the Same Origin Policy in JavaScript. Once I implemented the JSONP, the entire function
function getJSON() { var url = 'http://www.domain.com/webservice.asmx/function'; $.ajax({ type: 'GET', url: url, async: false, jsonpCallback: 'jsonCallback', contentType: "application/json", dataType: 'jsonp', success: function (json) { alert(json); }, error: function (e) { alert(e.toString()); } }); }
SSL, jQuery, and CDN
I just got whacked by a minor bug with SSL and the Google CDN (totally my fault, not theirs). I stuck the reference to the CDN in my master page not realizing one of the pages would be served up as secured by the vendor due to compliance issues. It made it through all testing because none of the staging/dev environments were configured for SSL and I was not made aware of the fact that we’d be serving the page up through SSL. Internet Explorer 8 prompted users about the insecure content before rendering the page. In their infinite wisdom, Microsoft decided to implement a new workflow for insecure content where the content is ignored and the page renders immediately with the unsecured content ignored. Since jQuery was used on multiple parts of the form, the site essentially broke. Google Chrome and Firefox seem to recognize the CDN as a trusted source and render the page as expected.
To fix the site, I added a javascript check to set the appropriate prefix to the CDN call:
<script>// <![CDATA[ var gaJsHost = (("https:" == document.location.protocol) ? "https://" : "http://"); document.write(unescape("%3Cscript src='" + gaJsHost + "ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js' type='text/javascript'%3E%3C/script%3E")); // ]]></script>
{Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.}
Problem
If you’re working in ASP.NET and ever ran into the error:
{Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.}
You’ll probably find that the stack trace gives you no useful information as to where the error actually occurred.
The Solution
For Response.Redirect, use the overload function (Response.Redirect(String url, bool endResponse)) and pass false into the EndResponse parameter:
[csharp]Response.Redirect ("nextpage.aspx", false);[/csharp]
For Response.End, you’ll need to call the HttpContext.Current.ApplicationInstance.CompleteRequest method instead of Response.End to bypass the code execution to the Application_EndRequest event.
Details
The error occurs when you use Response.End, Response.Redirect, or Response.Transfer.The Response.End method ends the page execution and shifts the execution to the Application_EndRequest event in the application’s event pipeline. The line of code that follows Response.End is not executed. This problem occurs in the Response.Redirect and Server.Transfer methods because both methods call Response.End internally.
Detecting ASP.NET debug mode
The Problem
Recently I ran into a situation where I needed to debug ASP.NET code in a production environment that we had no control over. The server was managed by a third party support team and we deployed to a staging environment through a custom web deployment utility they built.
Of course, the code ran locally and on our internal staging environments with no issues but when deployed to the client’s remote staging servers, the application was encountering odd errors that we couldn’t replicate.
At this point, I wanted to add code to the web application that could be turned on and off without having to recompile deploy new dlls because of code changes in the code behind. With this particular client, code changes would trigger security scans that took over a week to complete and we were short on time.
The Solutions that Should’ve Worked but Didn’t.
Page Tracing wasn’t working. I remembered the #if Debug and HttpContext.Current.IsDebuggingEnabled statements worked rather well in other projects.
So I added:
#if Debug //Debug code here #endif
to the web application. Nothing happened so I tried:
if(!HttpContext.Current.IsDebuggingEnabled)
but it kept returning false even though debug mode was set to true in the web.config file.
The Solution (that worked!)
Finally I got the bright idea to read out the debug setting out of the web.config and execute code if the debug flag was set to true. How to do so wasn’t exactly obvious though.
After some searching, I finally figured it out and here’s the code snippet that will execute only if the debug flag is set to true:
System.Web.Configuration.CompilationSection cfg = (System.Web.Configuration.CompilationSection)ConfigurationManager.GetSection("system.web/compilation"); if (cfg.Debug) { Response.Write(ex.ToString()); }
Why Didn’t the Normal Debug Statements Work?
The issue was that the machine was configured as production. The machine.config overrode the web.config since the <deployment retail=”true”/> switch was set in Machine.config.
This setting disables Page.Tracing & #If Debug and always sets the IsDebuggingEnabled to false. This was done by Microsoft as a security precaution for companies so they could ensure no applications were deployed with debugging enabled by mistake.
Bonus! How Do I Loop Through All Session Variables in C#?
I wanted to see what the session variable values were during execution of the page with the caveat that it would only run if the debug flag was set to true.
<% System.Web.Configuration.CompilationSection cfg = (System.Web.Configuration.CompilationSection)ConfigurationManager.GetSection("system.web/compilation"); if (cfg.Debug) { for(int i = 0; i < Session.Contents.Count; i++) { Response.Write(Session.Keys[i] + " - " + Session[i] + "<br />"); } } %>
I added the code directly to the bottom of the aspx page since I didn’t want to modify the code behind and voila! Once the code was added to the page, we found that the expected session variables weren’t populating correctly on the remote server. Unfortunately it required a code change to resolve the issue but I never would have found the cause without the above snippet of code.