Coding and the Dangers of Familiarity: Keep Your Senses Sharp

When I started at my current company, we essentially had one major project that everyone in the team worked on. It was a client that we had been working with for a long time.  It was a fun project to work on, and I learned a lot about ASP.NET MVC and Sitecore. Even when the project closed, I had no regrets about working on it for nearly two years, with very little other projects coming up during that time.

It wasn’t until the project closed that I realized how it programmed me into doing a certain set of coding practices. They weren’t particularly bad practices, but you could say they weren’t the accepted, best way of doing things. Soon, I was being assigned to projects where the best practices and/or frameworks were in use and I was expected to use those. I’ll give you two key examples, which were both shocking once I realized what I had not done:

  • Glass Mapper. I started a new project where Glass was being used extensively. I had some small training/research on Glass in the past, but this was first project where I had to use it. I did end up using it somewhat effectively, but what shocked me was how suddenly, my defensive coding instincts did not kick in. For example, for 1.5-2.0 years, I was used to doing this:
if (item != null && item.Fields["Heading"] != null && !string.IsNullOrEmpty(item.Fields["Heading"].Value))
{
   ...
}

The second I would use .Fields[] call in Sitecore development, I would know to do extensive null checks; it’s the way I was trained – but now, I was not using that call anymore. The code was completely different, and so I did not even think of checking for null for some reason. I don’t know why I wouldn’t check for null – maybe I thought Glass would take care of it and never return null? Silly me.

  • Logging. I learned Sitecore development in an environment where I never had to add logging in case an error occurs. My former co-workers that wrote the site added a global try/catch around everything, so that whenever some code in a controller errors out, the details of the error would be entered into a record in an Exception (SQL) table. Essentially, I very rarely or never had to use Log.Error to write an error to the Sitecore log, since the Exception table would always catch that. Well, this convenience turned me into a poor developer; I realized this as soon as some code I wrote went live for a new project. It unexpectedly errored out, but I had no way of finding out what the error was because the site had a custom error page.

This is just my personal experience, and I don’t mean to rag on the project that taught me how to do Sitecore development, but the point I’m trying to make is: if you do the same thing over and over, and suddenly have to do something new, make sure you do some common sense checks before committing the code; namely:

  • Null check all the things.
  • Log information, warnings and errors for each functional part of the code that will be running.
  • Also, will your change negatively affect something that you did not intend? Carefully observe the differences between your new code and the old code.

Additionally, If you’ve been working on one project for a long time, and the development practices generally used in that project are not optimal, keep you coding senses sharp by learning about the best practices in your spare time. Read articles, watch videos, create a Sandbox project which includes those better practices in use. If you have any similar experiences, I would love to read them – thanks!

Advertisements

How to Disable or Enable a Field in SPEAK

I’m not sure if Sitecore Rocks is the only way to do this, but I recently had to enable a disabled field of a SPEAK form. I figured you would be able to change field settings  in the content editor of Core, but I couldn’t find any way to do it from there. This post will describe how to change field properties through Sitecore Rocks; if there is another way to do this, please let me know through the comments. In my case, I was using SPEAK 2 with Sitecore 8.1.

  1. Open your instance via Sitecore Rocks and navigate to your app’s task page in the Core database.
  2. Right click the Item and select Tasks -> Design Layout.
  3. You should see some fields under Renderings and Placeholders. Double click the field you wish to edit.
  4. On the right, a properties dialog will appear.
    1. To disable the field – which will prevent text entry and make the background gray – set IsEnabled to False, IsReadOnly to True and add disabled=disabled to the  Parameters field.
    2. To enable the field, set IsEnabled to True, IsReadOnly to False and remove the disabled=disabled parameter.

Hopefully this helps other SPEAK developers out there! Feedback is appreciated.

Data at the root level is invalid. Line 1, position 1.

I recently ran into this error in Sitecore 8.2 when trying to change a link in a field in Sitecore. The field appeared blank,  so I clicked “Insert Link” and a Sitecore modal popped up displaying this error: “Data at the root level is invalid. Line 1, position 1.”

Sometimes when an invalid value is entered into a link field in Sitecore, the field will still appear blank to the casual observer. This of course, does not mean that the field contains no value at all. It just means that the field does not contain a valid link.

To resolve this issue, in the Content Editor click the View tab, then check Raw Values. The editor will refresh, and you should see something in that field of yours. It might be an ID or some form of garbage data. Clear that out completely, save the item, then uncheck Raw values. You should now be able to insert a link into the field. Hope this helps!

 

 

Resolving ClearScript V8 assembly issues

I recently worked with a colleague on a ASP.NET MVC / Sitecore project that had some references to ClearScript, which is a 3rd party assembly that lets you add and run scripts from C#/.NET. We noticed issues with trying to publish files from the solution to the webroot, which always seemed to break the site. The most common issue was with ClearScript. These issues resurfaced as we refactored the solution and made subsequent QA deployments to the client’s servers.

The first thing we did to fix this was reinstall ClearScript and JSEngineSwitcher through Nuget. We then kept making code pushes to the webroot until we encountered a new error, which we usually had to install through Nuget as well, or troubleshoot/fix in other ways. Many of the assemblies were way out of date, since the solution had not been updated in a long time. Also, because the webroot was part of the solution, we found that some Nuget packages were installed into the webroot project, not the Web project that we were building out of, which also caused issues. To update this, we right clicked the solution and selected Manage Nuget packages for this solution, then checked each package and clicked Manage, and checked the box for the Web project.

We eventually got the code pushes to the webroot to work. The next problem was moving the code changes to QA. The main issue we ran into was an error stating Could not load file or assembly 'ClearScriptV8-(32 or 64).DLL' or one of its dependencies. The specified module could not be found. Some solutions for this issue:

  • Right click the IIS application pool and select Advanced Settings. Change the value for Enable 32-bit Applications to true.
    • Some people have had success with the opposite (setting it to false). I am still not sure what effect this value has.
  • The error can mean that the ClearScript DLLs reference another DLL that is not present on the current machine. This makes sense considering I did not get this specific error on my machine with the same bin folder and site files. I looked into this and it seems like different versions of ClearScript require different versions of Visual C++ Redistributable:
    • For ClearScript versions 5.0-5.3, install Visual C++ Redistributable 2012.
    • For ClearScript versions 5.4 -?, install Visual C++ Redistributable 2013
    • I installed both 32-bit and 64-bit versions of both, although I’m not sure if that was required.
  • In my case, neither of the previous solutions worked, and it turned out that instead of copying over the bin to the QA server files and merging, I had to delete the bin folder and copy over new from my local webroot, which ended up fixing the issue.

I hope this helps others out there, this issue was quite an annoyance!

 

 

The breakpoint will not currently be hit. The source code is different from the original version

If you debug web applications frequently, you probably see this message in Visual Studio a lot. You set a breakpoint and attach to process, but the breakpoint is not active. If you hover over it, you will see this message:

The breakpoint will not currently be hit. The source code is different from the original version.

To begin, let me explain why you got this message.

You made a change to a method, view, class, etc, but you didn’t build the project before attaching to w3wp.exe. That’s all. Note, it’s best to just use ‘Build Solution‘ rather than ‘Rebuild Solution’. I’ve had times where I tried a Rebuild but nothing changed. I can’t quite explain it as anything other than a VS oddity.

Alternatively, you may get this message if you did build the project successfully. In that case, go to your web application and run the method/view, and VS should activate the breakpoints for you. In other words, sometimes you need to begin execution for VS to act correctly.

Now, onto that second part of the message…

To allow the breakpoint to be hit when the source code is different, right-click on the breakpoint, choose ‘Location…’, and turn on ‘Allow the source code to be different from the original version’.

Danger-sign-B

Do NOT allow the source code to be different from the original version.

There may be some weird situation where you actually want it to be different, but I don’t know of one. This is kind of like in VS 2010, where the build fails, and VS asks you if you want to run the application anyway… same weirdness level.

If you DO set allow the source code to be different, your breakpoints will be active, but they won’t highlight the entire line.. causing all kinds of debugger oddities and bugs.

Take this example…

not fully

Sure, your breakpoint works now, but it’s not going to run anything past ‘products’, which causes an exception in the debugger. This can get even more weird as you continue debugging. Oh, and building won’t do a thing.

So, things to remember:

  • Always build before attaching
  • Never allow the source code to be different

 

Happy Debugging.