Customize AuctionWorx Without Breaking Upgrades
AuctionWorx is a mature .NET platform. When you customize AuctionWorx, how you do it decides whether it stays easy to upgrade or turns into a maintenance problem. Systenics, a RainWorx Premium Partner with 15+ years on the platform, puts it plainly: the most expensive mistake an auction company can make is welding custom business logic into core platform files.
This post follows the approach in Systenics’ AuctionWorx customization guide and adds some general .NET practice.
What goes wrong when you edit core files
Editing a core file is fast. You find the line, change it, and move on. Then RainWorx ships a security update or a new version, and your edits conflict with it. Nobody can just apply the update, because it would overwrite your changes.
Now a developer has to:
- Extract both versions of every modified file
- Diff them line by line
- Re-apply your changes by hand to the new version
- Test everything to make sure the merge didn’t break anything
The cost depends on how many files were touched and how well the changes were documented. It repeats with every release. Systenics’ post on upgrading without losing customizations makes the same point from the other side: if you can’t quickly list what you’ve changed, someone probably edited the core.
The upgrade-safe approach
Treat the AuctionWorx core as something you extend, not something you edit. Systenics describes three practices:
Separate assemblies. Keep custom business logic, domain models and external API clients in their own class library projects, without modifying the main web project. Your code references the core. The core knows nothing about yours.
Lifecycle events and hooks. React to things like listing creation, invoice generation or bid placement through the platform’s event and service hooks instead of rewriting the code that raises them.
Theming discipline. Change the look through override views, partial views and dedicated CSS bundles. Don’t edit the base templates.
Because it’s .NET, partial classes can also extend a core model from your own project. Check what your version of AuctionWorx supports before you rely on any one technique.
Examples of the split
Custom fee logic. Wrong: edit the core invoicing code to add your commission rules. Right: put the calculation in your own assembly and call it from a hook, so the core invoice code stays as shipped.
Custom bidding rules. Dutch auctions, sealed bids and make-an-offer flows are all things Systenics builds as extensions. Its Dutch auction add-on is one example. The pattern is the same everywhere: your logic lives in your code, and standard English auctions keep using the core.
Mobile API additions. Add your own endpoints in your own project rather than in the core API project. Systenics’ mobile apps connect to the AuctionWorx backend through REST APIs and SignalR, so any change to those contracts needs to be tested against the apps.
Database changes
You will sometimes need schema changes. A few habits keep them manageable:
- Add your own tables and columns. Don’t rename or drop core ones.
- Keep every change in version control with a date and a reason.
- Avoid changing core stored procedures.
- Test your schema changes against the upgraded core schema in staging first.
Undocumented schema changes are a common failure point in upgrades. Systenics calls them out in its own upgrade FAQ.
Test against the new version before you upgrade
Clone production to a staging environment, install the new version there, and work through your custom features and the core workflows: bidding, invoicing, payments, custom views and any API endpoints. If it passes on staging, the production cutover is far less risky.
Assessing inherited technical debt
If you inherited a site with core edits, the way forward depends on how tangled the changes are.
A handful of edits can usually be moved into an extension layer in one focused effort. A few dozen across several controllers take more coordination. If edits are scattered through the business logic, step back and ask whether refactoring or a rebuild makes more sense. In each case, get a scoped estimate before you plan.
The cost of an upgrade-unsafe site compounds with each release. Fixing it earlier is cheaper.
Long-term view
Operators who treat the platform as infrastructure, not a project to keep modifying, tend to stay current with upgrades because upgrading isn’t painful. Invest in clean architecture early.
Ready to talk through customization strategy for your AuctionWorx deployment? Let’s talk about upgrade-safe architecture.
Related Resources:
Frequently asked questions
Have an AuctionWorx project in mind?
Talk to the team that wrote this guide.
