LavaBlast Software Blog

Help your franchise business get to the next level.
AddThis Feed Button

Slash your ASP.NET compile/load time without any hard work

clock December 1, 2010 09:18 by author JKealey

Jason has a cool eye :) FranchiseBlast, our franchise management platform, is a ‘large’ solution inside Visual Studio which currently contains 35 projects. In total, we manage over 60 interrelated projects, and have always been concerned at improving the compilation/load performance on our development machines. This post is a quick summary of what we did to keep things as fast as possible.

Personally, when it starts taking over a minute to compile or load my application, I start throwing things. This was the case early this week and with a bit of work, I managed to cut down things by an order of magnitude (from around 140 seconds down to around 14 seconds) with only software changes.  This is what prompted me to write this post.

There are three things worth improving:

  1. Compilation time
  2. First load time (ASP.NET)
  3. Application speed / database performance

 

I only want to talk about the first two; the only tip I’ll give you for #3 is to get your hands on a profiler such as dotTrace as it is a real time saver. 

Get better hardware (Big impact)

You’ll get the best bang for your buck by upgrading your hard disk, especially if you’re using a single 5400 RPM or 7200 RPM drive (download benchmark software to evaluate your current disk). Our projects are stored on a solid state disk. We currently use Intel X25-M G2, but the RevoDrive x2 looks much faster (basically a RAID-0 array of SSDs) if you have an available PCI-Express x4 slot. If you’re cheap and find the SSDs to be too small, just get two large 7200 RPM drives and put them in RAID-0. Make sure you’ve got a robust backup solution.

We have 12GB RAM on our development machines and a recent Core i7 processor, but nothing fancy. This is more than sufficient.

Store your temporary IIS files on your fastest disk or a RAM disk

Depending on the amount of RAM you have, it may make sense to use a RAM disk. I use my RAM disk for my temporary internet files and for IIS’s temporary folder (compilation results). I haven’t measured specific performance details but since I have so much free RAM, might as well try use it in creative ways.

To speed up the first load time, you can tell IIS to store its temporary files on your RAM disk (or fastest disk) by changing the following setting in your web.config files:

<compilation ... tempDirectory="q:\temp\iistemp\"> ... </compilation>

 

You can either change your project files directly, or, if you’ve lazy and have numerous applications running on your development machine (like I do), update the system-wide web.config files. Note that you need to update this for each runtime version of the Framework and, if running a 64-bit machine, for both Framework and Framework64. On my machine, I needed to modify the following files:

   1:  C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Web.config
   2:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Web.config
   3:  C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\Web.config
   4:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Web.config

 

Trade-off: If you save your RAM disk when shutting down, you’ll notice how much longer it takes to reboot. I can live with that, rebooting only once every couple months.

Review a few magical settings (Most impact)

When an ASP.NET website is loaded for the first time, it pre-compiles all your pages and user controls. Once done, everything runs faster. This is great for production websites, but horrible for your development machine. Why?  When programming, you’re usually only modifying a page or two (or back-end code). You’ll iteratively make a change, compile, launch the website, test, and start over; often dozens of times. A two minute compile/load time (like we had) forces you to lose focus and get distracted. The following setting makes pre-compilation more selective, making the first load time massively faster in development scenarios. On my machine, it cut the first load time from around 74 seconds to 6 seconds.

<compilation ... batch="false"> ...</compilation>

 

While on the subject of random boolean flags that make your life better, I should mention the following:

<compilation ... optimizeCompilations="true"> ... </compilation>

This flag has a number of gotcha’s that are documented here. I’ve enabled it for now, although my quick tests didn’t show any significant performance improvements compared to the previous one. However, I was probably not testing the right thing.

Restructure your projects

Try multiple solutions

About a year ago, we took 50% of our least used projects and moved them into a secondary solution. We compile that solution only when changing one of these projects, once every couple months. After rebuilding the secondary solution, we copy the *.dll files to a separate folder. Our primary projects reference those pre-generated libraries. I should repeat this process again, but I like having all my projects in one place and splitting them was a pain. However, this is probably the only sustainable way to manage extremely large solutions.

Selectively build the necessary projects

Using Visual Studio’s Configuration Manager, I also created different active solution configurations in my primary solution with only a subset of the projects included in the build.  I can thus swap between configurations depending on my primary task (working on our point of sale instead of FranchiseBlast, for example). This can drastically reduce compilation time, but I don’t use it as often as I should because:

  1. I find the user interface slow to refresh (Visual Studio).
  2. My dependency tree is complex and going through the list of projects to remove those I don’t want built is a pain.
  3. I context-switch a lot and often hit cases where I modify a project and forget that is not included in the build.

 

A simpler option is to build only the current project (and its dependencies) instead of all projects. Just make sure you don’t accidentally break the build (recompile everything before a commit).

Parallel compilation (Big impact)

Following Scott Hanselman’s post, I setup my project to compile in parallel. I did add a few options to make it easier for me to see errors/warnings without MSBuild’s typical clutter. (I also had a post-build action using NAnt which I set to quiet). This reduced my full rebuild time from 96 seconds down to 16 (after a clean solution). In a typical recompilation, we’re talking roughly 8 seconds instead of around 66.

Title: Parallel Build
Command: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Arguments: /m $(SolutionFileName) /v:m /ds /nologo /clp:Summary;Verbosity=minimal
Initial Directory: $(SolutionDir)
Check: Use Output window.

Trade-off: Error messages aren’t nicely presented in the Visual Studio Error List tab and you are not notified when the build is complete. 

Other noteworthy attempts

Over time, I’ve tried a few things that didn’t work out. In general, they improved things slightly but I don’t use them on a daily basis due to the tradeoffs.

I tried putting the whole project (source and output folders) onto the RAM disk but its volatility scared me away, regardless of the performance enhancements (Off the top of my head, it was between 25% and 50%). I then tried putting my only project’s bin folders on my RAM disk (by creating symbolic links from my bin folders to my RAM disk). This also had a positive impact on performance, but not significant enough to warrant the kludge (around 25% reduction in compilation time).

I also found a few tips & tricks for larger projects on Stack Overflow. First, I tried putting ‘Copy Local’ to false for all project references. This gave me a 25% reduction in compilation time, but broke my deployment scripts which needed all the files in the bin folder.  Separately, I configured all my projects Output Paths to the same folder, avoiding content duplication on the disk. This also gave me a 25% reduction in compilation time. Oddly enough, moving this folder to my RAM disk did not impact performance.

Summary

I hope this post gave you some ideas on how to improve your compilation speeds and first load times. I didn’t intend to give exact benchmarks, as performance will vary greatly depending on your projects. However, the main lesson learned is that there are dozens of improvements you can make; it’s up to you to try them out and keep what works for you.

The top three time savers for us are:

  1. Setting batch=false in the ASP.NET configuration page. (Now ~10 times faster)
  2. Parallel compilation for our projects (Now ~8 times faster)
  3. Better hardware (Now between 2 and 5 times faster)

 

Honorable mention goes to splitting your solution files, even though it’s painful and time consuming process to setup.

Do you have any other tips & tricks you’d like to share with us?



Collaboratively Defined Business Strategy

clock March 31, 2010 13:54 by author JKealey

 

bookingblast For those of you who’ve been keeping track, we launched LavaBlast Software back in April 2007. A year later, we posted three software startup lessons about how we got started and followed up the year after that with four more fun software startup lessons. Now that Year 3 is complete, I should write another set of software startup lessons, but that can wait. Today, I feel we’ve come full circle because we’ve begun working on the type of fun project that we would have enjoyed doing three years ago, but couldn’t afford the risk. In a sense, it feels like a full circle and a new beginning for LavaBlast even though we’re simply working on a new product.

BookingBlast is going to be legen – wait for it – dary. Read on to know more!

Starting from scratch

Pretty much straight out of university, we started LavaBlast Software. We had no money so we had to be creative. By creative, I mean we had to be cheap, work hard and work on something low risk to pay the bills.  The recipe for success is simple and we’ve said it before. Let’s just say we sell to businesses and we keep the intellectual property. This strategy has allowed us to start from scratch and making a living. 

We already have BookingBlast’s building blocks and now have enough runway to execute on our idea.

Ramping up

Some may stop here – but that’s not enough for us. We have greater ambitions - we’re looking for something bigger - for a greater reward. Based on the assumption that it takes a decade to launch a successful business, we’re not even a third through. We’ve passed through survival and have been growing steadily, but we’re now anxious to move to the next level.

We feel we can get there by converting the enterprise-level software we’ve been producing to date into more scalable Software as a Service (SaaS) products. We’ve been wanting to do this since day 1, but needed short-term revenues.  We’re now re-investing into LavaBlast to give us this flexibility. (I guess that visit to an unspoiled private tropical island will have to wait.)  We toyed with a few concepts during the past year, looking for software products that:

  1. No per-client customizations (greater scalability)
  2. Sold to businesses, not individuals (faster revenue)
  3. Shorter sales cycle, lower recurring dollar amount per sale (easier to commercialize)
  4. Related to our existing work and/or future strategies (reuse and upsell synergies)

 

Hold your horses! I’ll describe BookingBlast’s awesomeness in a minute.

Context & Goal

Our short-term goal with this project is knowledge. We’ve been building enterprise software for a while and want to dumb things down and start aiming for higher volume, but we need to adapt our know-how. We see BookingBlast as a practice run whereas our business is a marathon.

Our long-term goal is growth, in terms of revenue and the size of the company.  Lots of the enterprise-level work we’ve done can be commercialized to a broader market but we need a longer runway.

Spill the beans already! What’s BookingBlast?

BookingBlast allows service-based businesses to accept online bookings. Reservations are accepted only during available time slots and deposits are paid online, in advance.

To clarify, our software will allow customers to:

  • Book your child’s birthday party online
  • Book mobile clowns/magicians/comedians online
  • Reserve a massage / spa services online
  • Book your chiropractor from their website
  • Book a photographer from their Facebook page
  • … and accept bookings/reservations in many other industries.

That’s it. It’s not rocket science. It’s been done already – there are many competitors in this space – the market exists. The barrier to entry is low. But that’s not stopping us, because we have a plan. What better way to test our plan than to go out and execute it?  The worst that will happen is sales will be lower than desired and we’ll still reach our short-term goal of knowledge. We’re not betting the farm on this – it’s a stepping stone in the context of our longer-term vision.

How did you come up with your secret master plan?

We understand that this is a marketing play more than a technical one. We’re not inventing a killer product, although we can be innovative in our implementation. We decided it was in our best interests to share our plans for BookingBlast with people from diverse backgrounds and get them involved in the process. Ian Graham of The Code Factory always says the engineering students/graduates from the University of Ottawa are more secretive than the ones from Carleton University and we decided to prove him wrong. We openly solicited feedback on Google Wave and at TeamCamp. In the end, we found that we’re not that crazy after all as this validated our initial opinions. We did discover a few interesting twists which we plan on using, however.

Therefore, our plan is not secret – you’ll hear more about it when our product will be in beta. However, here a few lessons we learned from our experiences with collaborative planning.

Phase 1: Internal research

We looked around to find competitors and market penetration strategies. We discussed this internally over a coffee and did our homework. I produced a one-page executive summary of my initial plans.

Phase 2: Feedback solicitation via Google Wave

We published a private wave and invited two dozen random people. We made sure to invite people who were not extremely close to us because their feedback would be biased. We made it clear that the participants could feel free to ignore us as we didn’t care to force anyone into open collaboration, especially if they were busy with their own work. We found that the people least close to us were the ones who contributed the most to the discussion. Within 24h, the discussion had grown to approximately 8 times as long as the original executive summary. Within the next 48h, the discussion grew a bit more, with a few late-comers giving their comments.

The early discussions were the most valuable. They brought in new elements and got everyone involved. They definitely changed our strategy. However, as the discussion grew, I felt that most people lost interest because there was too much to be read. The barrier to entry had been raised, which caused most of the late-comers to elect not to participate. Initially, we thought this was a bad thing as we wanted more feedback, but in retrospect, we feel that what needed to be said was said early on. Had we discussed the same material with each person individually, we would have elicited the same comments over and over. Redundant feedback is not useful (other than for validation) and is a huge time waster.

In conclusion, open collaboration is a great technique to elicit feedback very quickly. I am greatly thankful to those who participated.

Phase 3: Feedback solicitation via TeamCamp

jkjp Ottawa’s primary co-working location, The Code Factory, hosts a bi-monthly event initiated by Chris Schmitt called TeamCamp. Once in a while, TeamCamp will have a pitch night where the participants pitch their idea to the group and get feedback. This is a very informal round-table setup but you get to chat with interesting people in Ottawa. A few weeks ago, I pitched BookingBlast to the group. This was great validation for our online booking software, as it proved that we had properly thought it out. Some new strategies were put on the table, but the biggest lesson learned is that you don’t need to spend months thinking about your project if you’re agile enough to adapt it along the way.

Furthermore, we finally had someone stand up and say our idea wasn’t good enough, something we had been waiting for since we started planning BookingBlast. Given the small scale of the project and the low barrier to entry, I was expecting most people to shoot our idea down quickly. Maybe I watch Dragon’s Den too much and read too many angel investor/venture capitalist blogs. In any case, this brought forth great discussions where it appeared other individuals were reading my mind while defending our online reservation software for me.

We’re now ready to start implementing the project! (In fact, we’ve already started and it is progressing nicely!) 

We need your help

We’ve posted a basic information request page on our website. If you know business owners that would be interested in participating in our alpha/beta programs, please have them sign-up to our newsletter.  We’re approaching the market in a different fashion that what the competition is doing, so we’d love to talk to business owners directly.

Since a good portion of our readers builds software for other businesses, we’d also like to talk to web developers that manage business websites.

Also, feel free to share your thoughts on BookingBlast and how to make it work in the comments. We’re thinking of openly blogging about thinks like SaaS pricing and gathering data concerning some of our strategies for future discussions and commentary.



jUCMNav Tutorial 5: Dynamic Stubs

clock February 21, 2010 07:40 by author JKealey

 

This is the last jUCMNav tutorial in a series of five. Below are links to other articles in this series.

 

The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Creating dynamic stubs
  • Dynamically selecting which plug-in map will be selected by a scenario

Links



jUCMNav Tutorial 4: Waiting places and timers

clock February 19, 2010 00:39 by author JKealey

 

This is the fourth jUCMNav tutorial in a series of five. Below are links to other articles in this series.

 

The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Introduce waiting places, timers, timeout paths
  • Introduce start point pre-conditions
  • Create a scenario with multiple start points
  • Create a path that triggers a blocked path

Links



jUCMNav Tutorial 3: Loop and scenario enhancements

clock February 18, 2010 00:38 by author JKealey

 

This is the third jUCMNav tutorial in a series of five. Below are links to other articles in this series.

 

The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Including a scenario definition inside another
  • Creating an Integer variable 
  • Writing pseudo-code inside responsibilities
  • Creating a loop

Links



jUCMNav Tutorial 2: Adding forks & joins

clock February 17, 2010 07:37 by author JKealey

 

This is the second jUCMNav tutorial in a series of five. Below are links to other articles in this series.

 

The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Creating an or-fork and or-join to model an exclusive choice
  • Creating an and-fork and and-join to model concurrency
  • Merging a start point and an end point
  • Creating a Boolean variable
  • Initializing variables inside a scenario

Links



jUCMNav Tutorial 1: Creating a simple path

clock February 16, 2010 07:46 by author JKealey

 

This is the first jUCMNav tutorial in a series of five. Below are links to other articles in this series.

 

The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • How to create a blank Use Case Map
  • Using the Path Tool to create a path
  • Presents the following path nodes: Start Point, End Point, Empty Point, Responsibility, and Static Stub.
  • Presents the “Refactor into Stub” menu option
  • Presents Components and how to change their fill color.
  • Explains how to bind path nodes to components.
  • Create a simple scenario

Links



Software engineers as salespeople

clock February 15, 2010 10:12 by author JKealey

LavaBlast is a small startup; we don’t currently have dedicated salespeople. I still do most of the selling at this point – I’ve got a background in software engineering, not sales. That may seem crazy until you realize that we don’t sell commercial-off-the-shelf software. If a prospect needs us to build custom software on top of our existing platform, the engineering team is involved in determining the scope (and therefore the cost presented in the quote). Because of the scope of the systems that we’re building, we have the “luxury” to spend more time on each individual quote and learning more about the prospect’s business. Adding a personalized touch in every quote gives us a competitive advantage compared to firms that pump out boilerplate text without analyzing the context.  I strongly feel that, for this type of sale, understanding the customer’s problems is much more important than having them understand your product. Furthermore, understanding/solving problems is definitely something software developers know how to do!

LavaBlast Software builds integrated software solutions for the franchise industry. Although the systems we build are similar because we reuse the building blocks which we’ve developed over the years, we understand that each franchise has different business rules. Understanding these rules before building custom software is of capital importance. This assertion holds regardless of what kind of software you’re building: everyone on the team should have a clear understanding of what needs to be built. Otherwise, you build software that only partially matches your user’s expectations and you need to go back to the drawing board to correct it.

Don’t get us wrong; we’re not fans of the Big Design Up Front (BDUF) approaches such as the waterfall software development model. We follow a more agile development methodology but there is one thing we do with each and every new franchisor client that approaches us: we model their business processes using a visual notation called the Use Case Map notation, a subset of the User Requirements Notation. This helps us understand their business and what they need built. We’ll come back to this notation in a minute.

Communicating business processes

Most business processes are simple (and should be), but a few are not as straightforward. Imagine an online store that sells quilts: the customer goes to the online store, chooses a quilt or two, provides payment, and the warehouse ships them. Simple enough? Add a few requirements to make it complex:

  • a customer can put a particular quilt (a unique hand-made design) on hold and provide payment for it within a week
  • customers can visit the warehouse and make purchases directly – it takes 24 hours for the website to be notified of stock changes
  • the store also receives telephone/fax orders
  • a customer can return a quilt for a full refund with 15 days, in person or by mail.
    These few extra requirements make the whole process a bit more complex.  In real life, there are always dozens of these added constraints. Some are very infrequent whereas others cause problems on a daily basis. Some can be solved by a better process while others can only be mitigated (especially things like delayed notifications) – you need to understand the context to be able to represent the current process and differentiate it from what you see as the ideal process to be implemented. However, as you are the developer and not the domain expert, you need to effectively communicate with the other stakeholders in order to create the best system. In most cases, your best guess is not sufficient.
    We’ve found that the best way to communicate these processes with our customers, who are not in the software world, is by using the User Requirements Notation. The notation provides a way to visually represent processes very quickly. Spending a few minutes designing a Use Case Map is akin to drawing on a whiteboard, with the added benefit of being a persisted artefact that can be “executed” to visualize certain scenarios. Additionally, the Goal-Oriented Requirements Language (the other half of the User Requirements Notation) allows the designer to compare different processes in terms of non-functional requirements such as performance, maintainability, security, etc.

Better than drawing on a whiteboard

Back in 2007, we’ve talked about the Use Case Map notation and jUCMNav in our initial blog post. To celebrate the release of jUCMNav version 4.2.0, we thought it would be nice to produce a series of tutorials that show you how to create your own model using jUCMNav. In case you didn’t know, LavaBlast’s co-founders have contributed massively to jUCMNav in the past five years. We’re responsible for 60% of the code in this open source project which we started during our time as undergraduate software engineering students at the University of Ottawa.

The following is a short 90 second video that gives you an example model and a very quick overview of what can be done with the notation and the tool. Stay tuned to our next blog posts to see us build this example from the ground up. The overview and the tutorial are intended for people with a background in software development. If you wish to introduce the notation to someone outside the development community, I would recommend starting with simple screenshots instead of showing the tool (which, in the end, should only be used by developers).

Conclusion

We hope you found this introduction interesting and that you’ll not only watch our upcoming tutorials but also download jUCMNav (an Eclipse plug-in) and play with it!



BlogEngine.NET 1.6 Breaking Old Links

clock February 12, 2010 10:17 by author EtienneT

UPDATE: BlogEngine 1.6.0.1 will fix this problem

Download BlogEngine 1.6 Binary Patch (drop in your bin folder)

We recently installed an open source error logging project called Elmah on our BlogEngine.NET because we noticed that comments were broken on our blog and some people informed us of other errors.

After installing Elmah, we found out that we had a lot of exceptions like this:

The file '/post/2008/01/Attach-to-Process-with-one-shortcut.aspx' does not exist.

After some investigation, we found out that a lot of the links leading to our blog were broken!  This is bad news because we care about our Google rankings!

I investigated the BlogEngine.NET code a little bit because we considered this a major problem and found out that BlogEngine.NET changed the link pattern from:

http://blog.lavablast.com/post/2008/02/I2c-for-one2c-welcome-our-new-revision-control-overlords!.aspx  (the old pattern)

to

http://blog.lavablast.com/post/2008/02/11/I2c-for-one2c-welcome-our-new-revision-control-overlords!.aspx  (the new pattern)

The day is now required in the link. Otherwise, external links are redirected to an error page.

After investigating the code, I found out that the method RewritePost in the class BlogEngine.Core.Web.HttpModules.UrlRewrite was changed in svn revision 29143 from:

Post post = Post.Posts.Find(delegate(Post p)
{
    if (date != DateTime.MinValue && (p.DateCreated.Year != date.Year || p.DateCreated.Month != date.Month))
    {
        if (p.DateCreated.Day != 1 && p.DateCreated.Day != date.Day)
            return false;
    }
 
    return slug.Equals(Utils.RemoveIllegalCharacters(p.Slug), StringComparison.OrdinalIgnoreCase);
});
 

to

Post post = Post.Posts.Find(delegate(Post p)
{
    if (date != DateTime.MinValue &&
        (p.DateCreated.Year != date.Year || p.DateCreated.Month != date.Month || p.DateCreated.Day != date.Day))
    {
        return false;
    }
    return slug.Equals(Utils.RemoveIllegalCharacters(p.Slug), StringComparison.OrdinalIgnoreCase);
});

 

Days are now mandatory in the URL rewrite to lead to a valid post.  Our old links that were using the yyyy/mm pattern are now returning and error page, and without installing Elmah or double-checking links, I would probably not have noticed. .

The RelativeLink property of the class Post was changed at svn revision 8906 to change the pattern from yyyy/mm to yyyy/mm/dd.  This in itself was not a problem if the old links continued to work.  But with this new change to the UrlRewrite class, the legacy format no longer works.

I changed the code manually to fix our problem, but this might affect other BlogEngine.NET users as well.  If you have a pretty old blog where people link to your old blog posts, then you probably are affected.

After some investigation, this bug was introduced while fixing Bug 9212.

I made a temporary patch for those of you who run BlogEngine.NET 1.6 and are experiencing the same issue.

I changed the code in UrlRewrite to search posts a second time but ignoring days in the date if it didn’t find the post in the first search.  Here is my code:

var predicate = new Func<bool, Predicate<Post>>(includeDays =>
{
    return new Predicate<Post>(
        p =>
        {
            if (date != DateTime.MinValue &&
                (p.DateCreated.Year != date.Year || p.DateCreated.Month != date.Month || (p.DateCreated.Day != date.Day && includeDays)))
                    {
                        return false;
                    }
                    return slug.Equals(Utils.RemoveIllegalCharacters(p.Slug), StringComparison.OrdinalIgnoreCase);
                }
        );
});
 
// Search all post and include days in the search
// A valid link would look like this
// http://blog.com/post/2010/02/10/slug.aspx
Post post = Post.Posts.Find(predicate(true));
 
// We can't find this post, try to find it but ignore days in the path
// http://blog.com/post/2010/02/slug.aspx
// Some older blogengine.net site used this link pattern
// We want to preserve links to those sites.
if (post == null)
    post = Post.Posts.Find(predicate(false));

 

BlogEngine.NET developers are aware of this bug, but in the meantime, you can just drop this new version of BlogEngine.Core.dll in your bin folder to temporary fix the problem if you are using version 1.6 of BlogEngine.NET.

I highly recommend installing Elmah on your BlogEngine.NET to discover errors like these!

Download BlogEngine.NET 1.6 Binary Patch (drop in your bin folder)

kick it on DotNetKicks.com

Shout it



ASP.NET Regenerate .designer.cs

clock February 8, 2010 11:58 by author EtienneT

In this simple post, I want to share a quick tip with Visual Studio.  You probably encountered this problem before: you are designing an ASPX or ASCX form in Visual Studio and then for some reason an element you just added in the ASPX/ASCX is not available in the code behind.

If you are lucky you know exactly what you changed in the page to cause this problem and you fix it.  However, if you’re opening a file that hasn’t been worked on in a long time (maybe someone else did the most recent modification), it becomes difficult to know what exactly cause the .designer.cs automatic generation fail. There are a few common scenarios for this such as invalid HTML, missing or duplicate declarations, or unresolved references. Finding the core issue by hand is difficult because the designer does not let you know what the specific issue is.

Small Tip

To regenerate the .designer.cs file for a ASPX/ASCX, first delete the .designer.cs file, then right click on the ASPX/ASCX and click “Convert to Web Application”.  This will probably give you an error message that will help you find the root of the problem.  I noticed that there’s a difference in the error message you might get here versus when the file is opened in Design mode in Visual Studio.

For example, we had a .ASCX file where the .designer.cs file was not being generated when we modified it.  We could not figure out what the error was until we discovered this tip because Visual Studio did not give us any feedback.  Once I deleted the .designer.cs and ran “Convert to Web Application” on the file, I was prompted with an error message that informed me that we had a <%@ Register /> declaration in our ASCX that was also declared in our web.config file (and this was creating a conflict even if they both pointed to the same location).  Visual Studio could benefit from better error reporting for this particular scenario.

kick it on DotNetKicks.com

Shout it



Month List

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017

Sign in