Today I’m going to talk about the dreaded namespace changing (this also applies to project renaming). Most of the time, when you decide to change the project name and or namespaces in an application, there is almost always some hidden issue that pops up. It has been my experience that there is usually a different ‘gotcha’ with each application type (For example Windows Phone, Windows Phone Silverlight, ASP.NET MVC application etc..). This particular article will focus on a Silverlight application.
I have posted several namespace type posts before. One in particular here that relates to changing namespaces in an MVC application and how it changes the way routes are interpreted. I will be talking about another recent issue I had with namespaces and WebAPI in a future post.
What most seem to miss in Silverlight Application project / namespace changes (Including myself).
So I recently changed the namespace on one of my personal projects due to my personal issues with perfection and anal retentiveness for everything to be consistent and unambiguous. After doing this, I followed the typical steps most do when doing a rename like this. These entail the following:
- Update the Assembly information to match the new namespace.
- Update the WMAppManifest.xml file Packaging section.
- Update the App.xaml to reflect the new x:Class section.
- Update any XAML files to the new namespace. Update both the .cs and .xaml file (The .xaml files are updated in the x:Class section at the top of the page).
- Update all classes to use the new namespaces.
- Update the Package.appmanifest file with the proper entry point if updated and the Packaging section.
- Clean out (delete not just run a clean) the obj and bin folders.
- Rebuild the project. This will ensure that the files associated with the project are renamed appropriately to match the new namespace and project name changes. Not doing this can cause adverse affects.
After doing all of these things, most of the time, you have covered all your basis and everything will build successfully and run as expected…. but not always.
So.. What happened?
Funny you should ask. So I built the project asfter doing everything above and I got a successful build. So we are good right? Wrong! Once I started the project in debug mode, I always got an AgHost.exe exited error, but no diagnostics would run. No exception thrown. No nothing. The complete error I got every time was as follows:
AgHost.exe’ has exited with code -532265403 (0xe0464645)
The key here is the code. –532265… Usually, the exit code is –1, which is pretty much exiting the application, but expectedly. About an hour after Goggling the error code, I found an interesting SO post. There seems to be a bug in Visual Studio 2013 and 2015 that causes the Startup Object in the Properties section to be empty. To get to this section, right click the project and go to Properties => Application => Startup Object. See below for a visual.
Where it says not set, you should set this from the dropdown to the desired start App XAML file.
Hope this helps others from pulling their hair out.
Happy Coding !