Running EA VB.exe Add-in on server

[JdBAlten]

Using Visual Studio I wrote an EA Add-in using Visual Basic.
I've got it working fine on a client with EA installed.

Now I would like to schedule the add-in to run daily on a server.
The company policy however limits the installation of software on servers.

Is there any way I can run the add-in on a server where there is no EA client installed?

I do have the Interop.EA.dll installed with the VB.exe.
The VB.exe.config contains the reference to the EA RDBMS and user id password.

[Geert Bellekens]

I don't think so.

Geert

[qwerty]

You need to run it as a user. Open the repos with Repository.OpenFile2 to pass user ans password.

Running an add-in as a service seems to be tricky, if not impossible. I just remember there were some threads and have simply used a workstation with a logged on user for such purpose.

q.

[Geert Bellekens]

You need to run it as a user. Open the repos with Repository.OpenFile2 to pass user ans password.

Running an add-in as a service seems to be tricky, if not impossible. I just remember there were some threads and have simply used a workstation with a logged on user for such purpose.

q.

But even then you'll need EA to be installed on the server no?

Geert

[JdBAlten]

Wow, quick responses.

And maybe I named the application mistakenly an add-in.
It basically is a Visual Basic application using "r = New EA.Repository" to create an instance for further processing the model contents.

Anyway, reading these responses, I think I have to either convince the administrator to install EA or find a workstation for running the application.

Thanks again.

[Geert Bellekens]

Wow, quick responses.

And maybe I named the application mistakenly an add-in.

You did, but it doesn't really matter. If you do something like New EA.Repository an then load a model then you are in fact running EA in the background.
I'm pretty sure that won't work if you don't have EA installed.
The interop.EA.dll just provides the facade to the EA application.

Geert

[JdBAlten]

Realizing this limitation, we installed EA on the server.
Now it works for the manual start of the VB application.

However, when trying to start it automatically using the Windows scheduler renders the same issue.

What might be the issue with the scheduler?

[Aaron B]

Most likely because the account being used to run your application does not have permission to create COM objects.  See:
http://community.sparxsystems.com/tutorials/603-75ea-as-an-unattended-windows-service-on-windows-server-2008r2-and-higher

[JdBAlten]

Unfortunately I'm still stuck on this issue.

I thought I had it running on a server, but that was for a ultimate license.

Is there any difference between a 'normal' and a 'named user' license?

[Aaron B]

EA licenses are available as either Standard or Floating Editions.

Standard license keys are entered directly into EA and register a single user.  Floating license keys are entered onto a server, which are then dynamically assigned to EA users on demand.

AFAIK "Normal" or "Named User" licenses would generally refer to the Standard edition license types.

Unfortunately I've not had much personal experience with running EA automation clients on a schedule, so those articles on the community website cover pretty much everything I know on the subject.

The user account running EA will need to be setup so that EA runs with a valid license key.  Any other issues will generally be related to insufficient permissions.