Please, if you are not busy, read my previous post on this subject found here. If you are in the middle of coding and trying to solve your migration issue, it is very long, you might want to come back and read it later (please do though, I think it is an important piece and something we need to address).
Having prefaced my article, lets talk about getting your Commerce Server 2002 site working in ASP.NET 2.0, and/or with SQL 2005.
Let's discuss SQL 2005 first. If you are looking for information before doing your database upgrade, feel at ease. Whether porting your existing site's databases to SQL 2005 or creating a new site and letting the installer and PUP process create your databases for you, it appears you will have no issues moving to SQL 2005, whether using 8.0 emulation mode for your databases or flipping them to 9.0 mode.
I've tested both a new install directly to SQL 2005. Restoring a SQL 2000 database set to SQL 2005. Detaching a SQL 2000 database set and manually attaching the ldf and mdf files to SQL 2005 and everything seems to work fine.
Yes, this is a good thing. Now you can use some SQL 2005 specific features in the rest of your site.
Now, for the ASP.NET 2.0 part. Here things get alittle more interesting. Before I get anyone too upset, our site *is* working and working with the same functionality it did before and working in ASP.NET 2.0. The items we currently have working are: Catalogs, virtual Catalogs, Discounts, Promotional Code, Baskets, Order Forms, Order Form Templates and all the pieces we needed for running our different Pipelines, including non-US currencies.
Everything, for the most part, worked without flaw, with very little modification. After migrating, or even just writing fresh, you will notice the resource file you most likely used to populate your messageManager object is not being loaded (and you are probably getting a parser error or a load error in your web.config file). If you weren't using a resource file, and were manually 'pumping' your messageManager, you probably don't need to read the rest of this, as you are probably up and running.
The issue, and someone more knowledgable in this area than myself may be able to shed more light on it, seems to be the difference in the assembly build processes of ASP.NET 2.0, combined with the way resources files are used/built. I am going to gloss over some of this, and many people may come back with ideas of building the resource files manually etc, and I don't want to discourage you, but I became pretty friendly with resgen and the assembly linker during this path, so I did alot of work on over coming this issue instead of working on 'how else can I do it'. After the second day, I started looking for alternatives.
It seems that there is another way, you don't have to populate the messageManager from within the web.config file, you can alternatively populate it from either the method where you are going to call the pipeline, or if you prefer, create it in the application on start method in the global.asax file and chunk him into the application object. WARNING: If you choose the second method, you will still need to pass him into your PipelineInfo object, or he wont be in scope there (found this out the hard way).
So, enough chatter, let's look at some code.
The first thing you need to do is fix your web.config file so the project will load.
Chop out the whole block, though save this somewhere, we will need to build our entries from it.
An example of this section:
Note: The webconfig file piece didn't save properly, I will fix this when I get in.
Next, open your solution. You will need to add a referencer to C:\Program Files\Microsoft Commerce Server 2002\Assemblies\MSCSAspHelpLib.dll, assuming that you didn't change your commerce server install path. (You probably won't already have this reference since if you used the web.config piece before you most likely never touched the messageManager manually)
For the next step, we are going to assume you are going to inline your messageManager guy in the method(s) you are running your pipeline in. For the sample, we are running a checkout pipeline and will only add the items we need for this. You would adjust the strings you are building based on what pipeline you are running, and obviously wouldn't hard code all this information in the code anyhow, this is sample only to get you up and running, I am not here to design your application ;)
MessageManager messageManager =
new MessageManager();
messageManager.defaultLanguage = "en-US";
messageManager.AddLanguage("en-US", 1033);
messageManager.AddMessage("pur_badcc", "The credit-card number you provided is not valid. Please verify your payment information or use a different card.", "en-US");
messageManager.AddMessage("pur_badpayment", "There was a problem authorizing your credit. Please verify your payment information or use a different card.", "en-US");
info = new PipelineInfo("checkout");
info["messageManager"]=messageManager;
basket.RunPipeline(info);
This will allow you to pass your manually build messageManager into your pipeline, so you can retrieve reply/error messages from it. It will need to have any strings you use from your web config file for discounts, checkout, etc to be added into it at the appropriate place these pipelines are run, whether you are running discounts, basket, checkout whatever.
If you would like to alter this to run from a centralized messageManager, move the messageManager declaration to the On Start method in your global.asax.cs file in your app_code folder, and after you build the messageManager, add the following line:
Application["messageManager"] = messageManager;
Then alter the above pipeline code to use this by replacing
info["messageManager"]=messageManager;
with
info["messageManager"]=Application["messageManager"];
I hope this information helps anyone who runs into a stumbling block with migrating their Commerce Server site to run in ASP.NET 2.0, but in case it doesn't, I will offer one better than Microsoft is offering you. Contact me through my blog and I will assist in any way I can with your migration. Hopefully, I won't have to do this for long, and Microsoft will go back to it's own policy of supporting it's mainstream products.