nopCommerce Plugin - Occasional "Temporary ASP.NET Files" Error

During the development of nopCommerce plugin, I am getting this not so useful null reference error. If you look careful enough though, this not so useful error did give me some hints though.

NullReferenceException: Object reference not set to an instance of an object.]
   ASP.<>c__DisplayClass1.<GenerateSubCategories>b__0(TextWriter __razor_helper_writer) in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\683926bd\eece36df\App_Web_ta.plugin.widgets.megamenu.views.widgetsmegamenu.megamenu.cshtml.4107764b.if7iazw3.0.cs:0

It is complaining about an object not found in the temporary folder. Occasionally the temporary folder is outdated and Visual Studio is not able to clear during recompilation. I manually deleted the temporary folder, recompile and everything work fine again.

nopCommerce - Register route for admin controller

In nopCommerce, if you ever create a new or customize a controller in admin and getting 404 not found error? Read on...

With the approach of inheritance of customized controller, it is essential to register a new route for the new controller.

As a developer, it is natural to look at the RouteProvider.cs in the Admin project.

The original Nop Code looks like this which seems promising, but it doesn't do it.

The actual place to look at is hinted by the first image. The correct place to look at should be the Nop.Admin.AdminAreaRegistration.cs.

You can add your routes in here. In my example, it is registering a route for PictureController.

FileInfo.MoveTo() does not overwrite. Surprising or Interesting?

FileInfo.CopyTo() has an overload method that allow you to overwrite if destination file already exists. It makes sense as you sometimes want to overwrite the file.

Similarly you would expect that is made available to FileInfo.MoveTo() but it is not, no big deal as we understand just because it is Microsoft .Net Framework, doesn't mean everything is available to you.

What I found funny though is the following comments by Microsoft.

Ref: https://connect.microsoft.com/VisualStudio/feedback/details/321351/fileinfo-moveto-show-allow-file-overwrite

Did they really sound surprised by such a feature?

I wouldn't be surprised if I am asked to do overwrite in Windows Explorer.

Solutions

Without using much brain power, this is natural to me.

It was actually interesting to see an interesting comments describing this feature as interesting.

FileSystemWatcher - The process cannot access the file 'filepath' because it is being used by another process.

FileSystemWatcher

"The process cannot access the file 'filepath' because it is being used by another process."

One of the famous error of using FileSystemWatcher is the file access issue. It happens because the FileSystemWatcher.Created event is raised and the file copy is still in progress. ie. The event is raised when the watcher is notified with new file creating, but the file is not yet completed with its creation. Make sense?

In the ideal world, the created event should be raised when the object is "created" but it is not. There are many ways to do handle it and has been written by any people. Without spending too much time on this small matter (from my bigger business requirements), I have written an extension method to do it. Simple but effective.

And we will use it like this. In the event handler, we will check if the file is usable before we copy.

Possible Improvement

There are 2 ways I see this. One way to improve this is create your own event handler that will truly raised when an object is "created" completely. That's probably what most people expected.

However, if you go down to my quick solution, you may want to put in a retry count inside the while loop so it will exit gracefully after a number of tries. This is now an infinite loop afterall!!!