Dotnetpanel Forums

Is there an ACWorks representative in the house?

As an authorised reseller for a hosting company I obviously don't have any sort of administrative rights on the web server that hosts my reseller account and customers.

At my request the host techs kindly installed "Easy API for dotNetPanel" with the "expiring" license number I got from the ACWorks website. However my initial attempts to run some sample code (classic asp) returns the error: "A valid Easy API for DNP license was not found".

I went back to the license page on the ACWorks website and this time the expiring license number was very different to the one I had passed to the host techs earlier.

So rather than keep messing them about trying different expiring license numbers I donated to get a permanent license number.

I assume that the "Item Number" in the PayPal receipt is the new permanent license number -- is that correct? I've had no other follow-up e-mail confirmation from ACWorks since donating (hint hint).

Anyway, I've passed the new license number on to the host and am awaiting a reply.

However, something has just occurred to me...

I had previously installed the 32-bit version of "Easy API for dotNetPanel" on my local workstation so as to get the sample code from the installation directory.

When I got the new permanent license number I entered into the License Manager of my local installation just to make sure it was good.

But now as an afterthought I'm wondering if the fact that I've already registered it locally is going to affect its acceptance when entered into the License Manager on the host's web server?

Please advise.

 

Soporose:

I assume that the "Item Number" in the PayPal receipt is the new permanent license number -- is that correct? I've had no other follow-up e-mail confirmation from ACWorks since donating (hint hint).

Yes, that should be your new permanent license. However the functionality should be exactly the same for both the permanent and the expiring license so that is not the root of your problem. Further, a license can only be used on one computer and using it on a different computer would yield an error message. However, since you have informed me of the problem I've arranged it so that your license gets associated with the next computer that uses it. Please note that License Manager will still show it as an expiring license for the next few days. Then it will automatically switch to a permanent license without further interaction on your end.

Lastly, lets talk a little about your actual problem. Your request is highly unusual as people who use Easy API for DNP normally have full access to the server but here are some tips that might help. They are listed in the specific order of importance.

1. Make sure that they have installed the right version for their OS (32 or 64 bit).

2. If License Manager shows that the license is valid (has not expired) and the TestCom.vbs does not show the "A valid Easy API for DNP license was not found" yet you get that error when you try to access it thru you ASP code, it means that your ASP code needs the right permissions. You need to find out your website's IUSR account and the AppPool's identity (this is usually Network Service but can vary). Those accounts need to have full access to the file that has the license information. The path to the license file may vary depending on the system but it is usually something like "C:\Documents and Settings\All Users\Application Data\AC Works\Easy API for DNP\Settings.xml".

3. Make sure that the website with the ASP code is set to run on .NET 2.0.

4. You may also need to run the site on Full Trust.

I hope the above information helps. Feel free to email me if you need more information.

 
Thanks very much for the prompt response, and thanks also for correcting my licensing stuff up.

I actually only went ahead with this project because someone else had told me I could use my reseller login credentials: http://forum.dotnetpanel.com/forums/p/7322/29651.aspx#29651

So is that not correct?

Make sure that they have installed the right version for their OS (32 or 64 bit).

The web server runs Windows Server 2008/IIS7, so I assume they would have installed the 64-bit version of "Easy API", but I'll check.

2. If License Manager shows that the license is valid (has not expired) and the TestCom.vbs does not show the "A valid Easy API for DNP license was not found" yet you get that error when you try to access it thru you ASP code, it means that your ASP code needs the right permissions. You need to find out your website's IUSR account and the AppPool's identity (this is usually Network Service but can vary). Those accounts need to have full access to the file that has the license information. The path to the license file may vary depending on the system but it is usually something like "C:\Documents and Settings\All Users\Application Data\AC Works\Easy API for DNP\Settings.xml".

OK, well there seems to be a few things there that may stop me dead in my tracks! For the moment I'll just have to wait until I get a message from the host confirming that the license has been installed, then see what happens. I don't know how far they'd be prepared to go in giving me extra permissions.

3. Make sure that the website with the ASP code is set to run on .NET 2.0.

According to the Website Properties, yes it is.

4. You may also need to run the site on Full Trust.

I'm fairly clueless about IIS so I looked up the implications of Full Trust, and I can't see any host giving that level of trust to a reseller on a shared server.

Things aren't looking very hopeful.

Yes, once it is setup properly you should be able to use your reseller login credentials without a problem.

Windows Server 2008/IIS7 comes in both 32bit and 64bit. They should install the proper version for their server.

Step #2 is most likely your problem and it is not unusual for hosts to have to grant special permissions when installing COM components in a shared environment. If they want they can actually give Everyone access to that file.

Full Trust does have it's issues and some hosts will simply refuse to do it. However, some applications simply need this kind of access. DotNetPanel's Panel is a good example. It either needs Full Trust or a modified version of Medium trust. If memory serves me right that is because that level of trust was required to connect to a web service. But since our component uses COM you may not need it. I only listed it as a last resort.

Let me know how things go.

 Thanks for the further information. I have passed your recommendations on to the host and so we'll see what eventuates.

 One point he raised was:

"...something to note is that the version this is for is version 2.0.1. DotNetPanel is now version 2.8.10."

Does this fact have any relevance that's likely to affect me?

 

Hi again ACW.

Unhappily I'm still not having any joy.

I passed the new non-expiring license number and the rest of your suggestions on to the host technician, and I later received a response that he had installed the new license number and that "Settings.xml was given Everyone permission".

However, now I'm encountering the following error:

error '80131500'
/dotNetPanel/default.asp, line 22

Line 22 is:
Set objEasyApiEs = CreateObject("AcWorks.DnpTools.EasyApi.EnterpriseServer")

Any suggestions as to the most likely cause?

OK, well, anyone else then?

Picture me begging on bended knees if it helps.I'm at a complete standstill here and have been for several days.

Is there anyone out there at all in dotNetPanel land who has successfully implemented "Easy API for dotNetPanel" on a hosted server? Two people who apparently should know have told me it can be done.

The most frustrating thing is that I feel I'm almost there, but I just can't put my finger on what's missing.

 

Alternatively... is there anywhere I can find some simple instructions on using the DNP API to create a new customer account, without taking the "Easy API" route -- preferably with sample code in classic ASP?

 

 Any and all advice MOST welcome!

 

Well, several more days go by and still no input from anyone. How sad. But before I just throw the towel in completely...

I've since discovered a bit more information and, limited as my knowledge of server configuration is, it really is looking like a server-side problem.

As explained in the previous post, when Line 22 of my asp code was:
Set objEasyApiEs = CreateObject("AcWorks.DnpTools.EasyApi.EnterpriseServer")

I was getting this error, and nothing else:
-----------------------------------------------
error '80131500'
/dotNetPanel/default.asp, line 22
-----------------------------------------------

I changed "CreateObject" to "Server.CreateObject" and now I get a little more information:

-----------------------------------------------
Server object error 'ASP 0177 : 80131500'
Server.CreateObject Failed
/dotNetPanel/default.asp, line 22
80131500
-----------------------------------------------

Most of the references I can find relating to "Server.CreateObject Failed" suggest that either:

• The relevant DLL is not registered properly; or
• The relevant dll(s) do not have the correct NTFS permissions, and that the group "Everyone" should have "Read" and "Read & Execute" NTFS permissions for the dlls.

These suggestions are supported by this Microsoft document

The next sad part is that, after installing "Easy API for dotNetPanel" on his server, my host doesn't seem to want to investigate the possibility of incorrect configuration on his side any further. His position now with regard to "Easy API for dotNetPanel" is that:

"It is absolutely unreasonable to use an API for an API. That's what you are doing. DotNetPanel comes with an API."

Is that a reasonable position? If it is, then it would seem that the developers of "Easy API" have wasted an awful lot of time.

The whole purpose of my going the "Easy API" route in the first place was so that I could use the one server-side language with which I'm familiar -- classic asp -- without having to get into .NET, XML, SOAP and what have you. It really did seem that "Easy API" was the easy approach.

Does anybody AT ALL have the knowledge to at least jump in here and comment with some authority?

Soporose:

I've since discovered a bit more information and, limited as my knowledge of server configuration is, it really is looking like a server-side problem.

You are correct, it is a server side problem which only the host can investigate and correct. The problem is that servers can be configured in a vast number of ways so there may not be a right solution across the board. However, I can say that you are not the first to ask for additional help with configuration and following the steps I outlined before has solved the problem. But as far as I know these have been their own servers to which they have full access.

Soporose:

The next sad part is that, after installing "Easy API for dotNetPanel" on his server, my host doesn't seem to want to investigate the possibility of incorrect configuration on his side any further.

I also understand this as it can be time consuming and I presume they are only charging a flat fee for hosting.

Soporose:

His position now with regard to "Easy API for dotNetPanel" is that:

"It is absolutely unreasonable to use an API for an API. That's what you are doing. DotNetPanel comes with an API."

Is that a reasonable position? If it is, then it would seem that the developers of "Easy API" have wasted an awful lot of time.

The whole purpose of my going the "Easy API" route in the first place was so that I could use the one server-side language with which I'm familiar -- classic asp -- without having to get into .NET, XML, SOAP and what have you. It really did seem that "Easy API" was the easy approach.

You can think of DotNetPanel as having two APIs: 1) a SOAP(web services) API and 2) the client DLLs that they use as a wrapper to the SOAP API. It is impossible for scripting languages such as classic ASP to use their client DLLs as they are meant to be used within .NET. It is conceivably possible for someone to connect directly with Enterprise Server's SOAP API using classic ASP but I've found that the web services security is so complex that it is impractical to go that route. You would likely still need other components installed on the server to help you connect. The complexity of the SOAP security is what has kept me from finding ways to create DNP providers for Apache and other Linux servers. It should be possible but I don't feel it is worth it.

Therefore, I know of no easier way to use scripting languages than Easy API for DNP.

ACW, thank you very much for your ongoing assistance. I really appreciate the trouble you are going to.

The head tech at my hosting company has agreed to persevere a little further, providing I tell him exactly what needs to be done. A big ask, considering my lack of familiarity with web servers, but here goes. I've put together the following list of instructions, based mainly on information previously received from you.

----------------------------
1. Uninstall/remove any traces of the previous installation of the "Easy API" MSI.

2. Ensure that any websites that will use "Easy API" are set to run on .NET 2.0.

3. Install EasyApiForDnpV2.0.1-x64.msi (Windows Server 2008/IIS7 on 64-bit machine).
QUESTION: Is any further action then necessary on the part of the host tech, such as individually registering the DLLs that have been installed by the MSI file.

3. Enter the license number into License Manager.

5. Grant EVERYONE access to the license info file Settings.xml. Path is usually something like: C:\Documents and Settings\All Users\Application Data\AC Works\Easy API for NP\Settings.xml.

6. Run the website on Full Trust -- some applications (such as dotNetPanel's panel) need this kind of access.
----------------------------

Are those steps correct? Any others that should be included? Let's get every likelihood covered in the one set of instructions,so I need to bother the host as little as possible..

QUESTION 1: Considering that EasyApiForDnpV2.0.1-x64.msi has been previously installed and the license number entered into that installation, will uninstall/reinstall affect the acceptance of the license information the second time round?

QUESTION 2: The currently available version of "Easy API" says it's for DotNetPanel version 2.0.1. My host's version of DotNetPanel is 2.8.10. Any significance?

QUESTION 3: Once installed, should calls to "Easy API" be available to any customer account under my Reseller Account on that server?

By the way, I offered to pay the host for whatever time it took to configure "Easy API", but he says he can't charge me for something they're not familiar with. Fair enough I guess, but it begs the question: Should there be a specific set of instructions available to hosts? If I can get this working I'll write an article around it which I'm confident will result in many more Resellers wanting to try the same thing.

TIA

 Well, here is the situation as it stands now...

My site's App Pool is set to 32-bit, so I provided the host with the 32-bit version of "Easy API" and requested that they uninstall the previously provided 64-bit version. They reported: DONE.

I also provided the following instructions regarding the 32-bit installation:

---------------------
Several DLLs will be installed by the MSI, but I'm sorry, I simply do not know if those DLLs have to also be separately registered. YOUR COMMENT?

NECESSARY CONSIDERATIONS:

1. Any websites that will use "Easy API" must be set to run on .NET 2.0.

2. Must grant "EVERYONE" access to the license info file SETTINGS.XML which
is installed by the MSI.

3. Run the websites on Full Trust. ACWorks says: "some applications (such as
dotNetPanel's panel) need this kind of access".
---------------------

Just received a response back that everything has been done. However, running my classic asp script still returns the following:

---------------------
Server object error 'ASP 0177 : 80131500'
Server.CreateObject Failed
/dotNetPanel/default.asp, line 24
80131500
---------------------

Omitting comments, all of the script code up to line 24 is:

---------------------
<%
Dim m_EnterpriseServerUrl, m_DnpUsername, m_DnpPassword, objEasyApiEs
    m_EnterpriseServerUrl    = "http://127.0.0.1:9002"
    m_DnpUsername        = "My-Reseller-Login-Name"
    m_DnpPassword        = "My-Reseller-Password"

' Line 24 is next...
Set objEasyApiEs = Server.CreateObject("AcWorks.DnpTools.EasyApi.EnterpriseServer")
---------------------

Unless you can see something wrong or offer a suggestion, I don't seem to have anywhere else to go. As far as I can see we've complied with all requirements.

But still hoping...

TIA

 Well, I've decided to abandon this as a complete waste of time, and I'm inclined to advise anyone else thinking of trying "Easy API for dotNetPanel" to just forget it.

If you run your own server and you really know your server-side configuration you might have some success.

But if you're trying to implement it as a Reseller (which I was assured was possible) and you run into problems, you're just going to waste an awful lot of time waiting for support that is promised but that never happens.

When the representative of ACWorks Software who goes by the board name of ACW stopped responding I sent an e-mail directly to ACWorks support. I thought I was onto a good thing when I got a reply from Felix Cardona, the owner of ACWorks, who promised:

"I am doing further tests to see what other guidance I can give you. I’ll contact you as soon as I have something."

Two weeks and several ignored messages later I've never had another response from him.

My host showed a lot of patience and was willing to persevere with the installation and configuration of "Easy API for dotNetPanel". I even passed the name, phone number and e-mail address of the head tech on to Mr Cardona, figuring that a short conversation between the two experts would soon resolve the problem.

Well, we'll never know, because Mr Cardona never contacted my host and he has never bothered to respond to any of my requests for an update.

Frankly, in the face of that sort of customer "service" attitude it doesn't matter whether the product works or not, or how good it might or might not be.

I've written a number of articles condemning that sort of attitude towards customer service, and publicly naming and shaming, and whenever I do I get responses from readers who regularly experience the same sort of thing and who are simply fed up with it.

Before you give anyone money or invest time in them or their products, do your best to determine if they'll be there when you need them. I've proven to my own satisfaction that ACWorks won't be there.

Hello Bill,

Let me start by saying that I am sorry things did not work out for you with Easy API for DNP.

Some things out of my control have monopolized my time and attention and forced me to travel out of the country. That said, I'd like to clarify that I never offered to call or contact your host personally. Experience shows that this type of troubleshooting can be very time consuming and I would have nothing more to add than what I have already shared with you here and in private emails.

Please keep in mind that this is a free product that we have made available for those who wish to use it - and many have, and continue to use it with great success. Those that wish to donate something may do so but it is not at all necessary. And even the ability to accept donations was at the request of users. We try to help as best we can as time and circumstances permit; which I think most will feel it is absolutely reasonable for a free product.

I believe you mentioned at some point hiring a developer to help you reach your goals going forward. I think that is the way to go in this case and wish you the best in your endeavors.

Regards,

Felix Cardona