I realise this is a very similar question to Stop SSMS from scripting SPs using sp_executesql?
However, they seem to have changed the behaviour with SSMS 2012.
If you have the ‘Check for existence’ option selected, as in:

… it now generates an IF NOT EXISTS for the proc about to be created, as well as an IF EXISTS for the previous drop proc, if, as I usually do, I select the DROP and CREATE option:

This forces it to script the CREATE using sp_executesql. It’s pointless, since you don’t need the IF NOT EXISTS check on the CREATE, if the DROP has just dropped it.
It doesn’t seem possible to have the one without the other.
Any ideas?
You can’t do this without the dynamic SQL because a stored procedure has to be in its own batch. Therefore you can’t say:
The only way to keep that in the same batch is to use
sp_executesql.If you’re going to script the
DROPandCREATEsimultaneously, just do it without the check for object existence. This will give you:Who cares if the
DROPfails? (It shouldn’t, because you just scripted from it!)If you’re scripting this for another system that might have the object, you’ll get an error message for the
DROPwhen it doesn’t, but theCREATEwill still happen, so you can ignore theDROPerrors. If you really want you can manually wrap theDROPstatements inTRY/CATCHbut I don’t think it’s necessary.If you need to do this for a lot of procedures, or if you really need the process to not generate benign errors, I suggest you abandon Management Studio’s primitive scripting options and use a 3rd party tool for this. They’ll have already dealt with many of the issues you haven’t yet come across, but will. I blogged about this:
http://bertrandaaron.wordpress.com/2012/04/20/re-blog-the-cost-of-reinventing-the-wheel/