Chris,
What are your errors? I have had ASPDNSF for two years, including product support and source license agreement. I have turned down at least 20 DNN & ASPDNSF projects until I am comfortable with something that is sort of stable.
On Friday, I got hold of the ML/DNN 7.2.1 vb source and just had a marathon session including real time debugging. ASPDNSF is a true hodgepodge of effort and code, and slowly but surely I am beginning to see the light.
IMO, the single most problem with ASPDNSF code is that it needs to be refactored. Not just for ML/DNN but for real world use. Just because a DAL exists in a module or a project does not mean that it is designed properly. The code contains all sorts of scattered UIL (user interface) mixed with BLL business logic) and DAL (data access) including interlaced and hard coded SQL string builders. It is no wonder that the documentation says
<quote>WARNING: You can easily define a pricing/level/extended pricing/quantity pricing/coupon scheme that NO ONE could possibly figure out how the actual pricing was computed. Our suggestion is to KEEP IT SIMPLE. If you use Discount Percents for levels, DON'T USE extended pricing, and TURN OFF coupons for the level, etc... If you want to define extended pricing for each product variant, then set ALL level discounts to 0, disallow coupons, etc... NetStore will ALWAYS compute A price for each product and the entire order, but YOU may not be able to explain how the price was arrived at to your customers. KEEP IT SIMPLE!</quote>
In other words, "we are not sure what is going to happen either."
Having said that, ASPDNSF seems to work once you understand their concepts and their terms. It took me three weeks to figure out how to uninstall and reinstall ASPDNSF, and I now I use scripting and a template to install DNN & ASPDNSF in a single shot.Once I figured out the simple XML import system, I had it uploading thousands of SKUs at a time, updating existing related data. I even have a script to clean up my database mess without starting from scratch.
For example, here's a bleeding edge LinqToSQL code snippet that builds an xml file from a live system for direct import into ASPDNSF:
Sub GetProducts()
Dim sd As New BaldwinDataContext
Dim products = <AspDotNetStorefrontImportFile>
<%= From p In sd.Products Take 1000 _
Order By p.SKU _
Select <Product>
<Name><%= p.Name %></Name>
<ProductTypeRef>Generic Product</ProductTypeRef>
<ManufacturerPartNumber><%= p.ManufacturerNo %></ManufacturerPartNumber>
<ManufacturerRef><%= p.Supplier %></ManufacturerRef>
<Description><%= p.Description %></Description>
<SKU><%= p.SKU %></SKU>
<ProductVariant>
<Name><%= p.Name %></Name>
<Price><%= p.Price %></Price>
<IsDefault>True</IsDefault>
</ProductVariant>
</Product> %>
</AspDotNetStorefrontImportFile>
MakeFile("products.xml", products)
Yes, that is normal Visual Basic code running in Visual Studio 2008.
The most serious problem with the current version of ASPDNSF and DNN is requiring portal 0. This means that you cannot use any other portal, which is a serious downfall. If you have a working DNN site with multiple portals, forget about adding ASPDNSF (although I almost have it working on other portals properly).
One thing I have learned is to open your site in three tabs, DNN admin, ASPDNSF admin, and DNN event viewer and open a system event viewer. Then, when something you do causes a problem, you have a way to find out why. The other thing is that when ASPDNSF behaves funny, stop immediately and find the cause. Otherwise, you will spend far too much time trying to remember how many things are broken. It is far too easy to compound issues and make it far more complicated than it really is.
I usually check the DNN event viewer first. Then I check the system event viewer for deeper problems.
90% of the problems I have experienced are due to an impedance mismatch between ASPDNSF and DNN paths.
Many simple App Config settings will break the admin site and make it unusable. A simple workaround for a development or staging site is to simple put the file exactly where ASPDNSF wants it. It's not pretty, but it will get you working again.
Be very careful switcvhing between dev/staging/production servers. Not only is it confusing, but a single mistake (think web.config) can make ASPDNSF crash your site and make all your portals unusable. Do not fool around with ASPDNSF on a production server just yet.
Other issues are often caused by the overly complex business rules. Ultimately I discovered I had used CAN instead of CAD for Canadian currency which did not work at all. Then I found a few more bugs in the continue checkout process. This morning, I placed my first test order from the site and it actually worked.
I really think that the ASPDNSF team has done a great job for beta release, but the product is still not ready for prime time. One thing that would really make a difference is to be able to export and import data including app configs as xml. I am working on a module that does that right now so I can send an xml file to support to try on an empty vanilla site to demonstrate the issues,
Back to your situation, there are simple workarounds that will get you online for the time being without the repetitive uninstall and reinstall routine. Feel free to leave me a message if you want more ideas about your specific errors/problems.
Let’s keep our fingers crossed.