This project has moved. For the latest updates, please go here.

Developing server-side methods in Aras gives you considerable control over the processing of data in Aras. However, the current development environment comes with its share of shortcomings. What follows is a description of one company's journey exploring different styles of server-method development along with the advantages and disadvantages of each. My hope is that this story will be a starting point for further conversation about what server method development in Aras should look like in the future.  In particular, I am curious about

  1. What style of method development is employed at your company?  Which of the following scenarios is it most similar to?  In what important ways does it deviate from the described scenario?
  2. What should server method development in Aras look like in the future.

Out-of-the-Box (OOTB) State

Out-of-the-box, Aras comes with a basic form for editing server methods. This form includes a syntax highlighting editor similar to what someone might find with Notepad++ or a similar plain text editing tool. In addition, the core methods available to you are presented in a pane along the right.

Pros Cons
  • Any developer can work on methods without any additional tooling installed on his/her system
  • Due to the locking process, development by multiple developers is certain not to conflict with each other
  • How to write method code is not obvious to the novice developer.  The entire notion that you are writing method code which will become a member of an object, and that this object and its private members are the arguments to your code is not similar to any other programming paradigm / environment I am aware of.
  • No intellisense makes it difficult to efficiently write code (due to time required to look up method names and signatures in addition to the time required to fix spelling and casing mistakes)
  • Compilation errors are not always displayed.  Unlike Visual Studio, compilation errors are only available when explicitly compiling the methods, and only for C# code.  The display of compilation errors for VB code has been broken from versions 9.3 through 11.0.
  • No step-through debugging.  While remote debugging can be utilized it takes a considerable amount of time to figure out how to set up and is cumbersome to use.  Edit and continue (where you can make code changes while debugging) is not supported.
  • The loose-coupling between server methods makes reusing code challenging.

Visual Studio Test Bed Project

One of the easiest ways to overcome some of these problems, is to develop a Visual Studio "test bed" project.  This project acts as a shell project into which server method code can be pasted into, modified, and debugged.  Once it is working satisfactorily, the code can be copied into a server method for further testing and/or deployment.

Pros Cons
  • Using Visual Studio gives the developer access to all of Visual Studios productivity tools including, intellisense, as-you-type compilation, step-through debugging, etc.
  • Differences in compilation between Visual Studio and Aras can prevent pasted code from compiling.  Ensuring that the test bed environment is the same as the method config file (e.g. the Option Strict settings in VB) could help with some of these problems, but was not tested at our company. What was noticed was that:
    • Shortcut property declarations (e.g. declaring Property Name as String) do not work with VB
    • Linq to XML (specifically for VB) does not work because the Aras editor changes capitalization of key attributes interfering with the meaning of the XML
    • Inline variable declarations in For Each loops do not work
  • Copying and pasting code between the server method and local development environment is cumbersome and tedious
  • The loose-coupling between server methods makes reusing code a challenge

Compiling Server Method Code into a Dll

One approach to overcoming these challenges is to compile server method code into a dll such that each Aras server method is just a single line call to code within the dll.  This dll is then deployed to the server upon code changes.

Pros Cons
  • All of the benefits of Visual Studio development stated above
  • Compilation settings are guaranteed to be the same between development and deployment.
  • Server methods do not need to be modified in order to make code changes
  • Consultants concerned about their intellectual property can obfuscate their code
  • Utilities methods are easy to develop and refactor using built in refactorings along with tools such as "Go to Definition" and "Find all references".  Code re-use is promoted at the same time.
  • Resources (such as SQL queries) can be embedded into the dll as resources so they don't have to be encoded into strings.
  • A more rational development paradigm (where server methods are essentially functions which take an item as an argument and return an item as a result) can be utilized
  • Standard source control systems can be more intuitive for developers than remembering to unlock methods.
  • Since dlls are not database specific, extra work is required to deploy code to only a single database
  • Use of deployment scripts and source control is required within a multi-person team to ensure that changes made and deployed by one individual do not conflict with those made by another.
  • Developers without access to the source control system and Visual Studio cannot contribute to server method development

Dll Deployment, Method Compilation, and App Domains

In theory, the story should have ended with the last configuration (i.e. compiling code into a dll).  However, a nasty little problem prevented this.  Our company has 660+ custom server methods in Aras including ones that are executed rather regularly (e.g. on each login or after each part get).  What we discovered was the following:

  • When we deployed server method dll's to the server (e.g. as a result of fixing a bug), IIS would essentially do a reset.  That is, it would create a new AppDomain with the new dll's and send all new web calls to the new AppDomain.  It would properly dispose of the old AppDomain afterwards.
  • In the new AppDomain, Aras did not have anything cached, be it ItemType metadata, or more importantly, compiled server methods.
  • Due to it's lazy compilation of server methods, Aras would wait to compile a server method until the first request came in requiring it.  It further appears that if a second request came in requiring the same server method before compilation was complete, Aras would trigger a second compilation of the same method instead of simply waiting for the original compilation to complete.
  • As a result, any deploy of dll's during times of high usage would cause the server to become unresponsive for approximately 5 minutes as Aras attempted to compile the tens to hundreds of server methods it needed to satisfying the large volume of requests coming into the server at any one time (say 120 unique users within a given hour).

Because the ability to work in an agile manner and deploy code changes to the server quickly was important to us, we developed a rather complex solution.  Instead of having server methods calling our code directly, an intermediate dll would load all of our server-method code dll's into a separate AppDomain.  This AppDomain would be loaded/unloaded whenever we deployed new dll's.  However, since IIS was not aware of this AppDomain, changes to it would not trigger an IIS reset, and the Aras method cache would remain intact.

Pros Cons
  • All of the benefits of compiling server method code into a dll
  • Dll's can be deployed at any time without interrupting server performance.
  • All of the disadvantages of compiling server method code into a dll
  • Complex additional code is required to set up and tear down AppDomains
  • All data must be serialized across AppDomains requiring a small performance hit as data is serialized from Items to strings and back again.
  • Aras custom server exceptions do not include the constructors for serialization across AppDomains.  This means that debugging errors is an additional challenge.


Last edited Feb 5, 2015 at 9:48 PM by erdomke, version 5


No comments yet.