Re: .NET API for 7.X - RESOLVED
I determined the fix to the issues I was having. Basically here are all the changes I did that resolved all issues I had originally and changes that resolved other issues: * Changed the Active Solution Platform of the Console application from the "Any CPU" default to "x86". This fixed the issue with the "is not a valid Win32 application error". Thank you Lyle! * The System Path environment variables were missing on the server. Somehow they were removed accidentally. We readded them and added the path of the APIs. Had a bump too where the actual folder name was not set to the path I set in the Environment variables but fixed that I got through. * I also had a problem later with SQL timeout apparently when attempting to setup the connection against a 630622 private thread. When I took that specific thread out of the equation it got through the GetListEntry line of code. * Fixed some other syntax issues with my code and it WORKED!! One funky thing I did discover though when confirming the CMDB Audit Log update (in this case was updating Name which is audited by default in CMDB 2.0.1) is that the table field shown when you click CMDB Audit Log in the CI that is affected you see the User ID of the Submitter of the asset. Not the user that actually updated the attribute. However, when you click "View" it takes you to a read only pop up of the CMDB:DefaultLog form where you can then see the "User" that made the update. (Why BMC did that...who knows). Thanks Peter Lammey ESPN IT Packaging and Automation 860-766-4761 From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Friday, April 23, 2010 11:21 AM To: arslist@ARSLIST.ORG Subject: Re: .NET API for 7.X ** It looks like you're probably missing a DLL, or the path to a DLL the API uses. This is the set of DLLs that I've copied into my bin/Debug directory to get it running: 08/25/2008 08:04 AM 1,163,264 arapi71.dll 12/23/2008 11:25 AM 950,272 arcni71.dll 08/25/2008 08:00 AM77,824 arrpc71.dll 08/25/2008 08:01 AM 167,936 arutl71.dll 12/23/2008 11:25 AM36,352 BMC.arnettoc.dll 12/23/2008 11:25 AM 499,712 BMC.ARSystem.dll 12/23/2008 11:25 AM 301,476 BMC.ARSystem.tlb 12/23/2008 11:25 AM32,768 BMC.ARSystem.Utilities.Common.dll 12/23/2008 11:25 AM 897,861 BMC.ARSystem.xml 12/23/2008 11:25 AM 118,784 BMC.Atrium.dll 12/23/2008 11:25 AM51,682 BMC.Atrium.xml 02/13/2008 02:32 AM 1,581,056 cmdbapi21.dll 10/18/2007 01:01 AM 9,830,400 icudt32.dll 02/06/2007 11:38 AM 696,320 icuinbmc32.dll 02/06/2007 11:37 AM 606,208 icuucbmc32.dll 12/23/2008 11:25 AM 249,856 log4net.dll 12/23/2008 11:25 AM 1,287,495 log4net.xml 08/25/2008 09:16 AM 397,312 rcmn71.dll 04/30/2004 01:40 AM 282,624 vc6-re200l.dll You don't need to copy them all into your run directory, but that makes it easy for development and testing. When deploying, that's also the easiest. However, you could also copy all the native DLLs to any other directory on the system and add that directory to your system Path variable. The .NET DLLs need to be in your application's deployment (run) directory in order to be picked up, since you can't add them to the GAC. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lammey, Peter A. Sent: Friday, April 23, 2010 6:51 AM To: arslist@ARSLIST.ORG Subject: Re: .NET API for 7.X ** OK. I was able to change my project platform from X64 to x86. That might at least tell my VS2008 console application to run in 32 bit mode. However now I get this error: FileNotFoundException was unhandled The specified module could not be found. (Exception from HRESULT: 0x8007007E) Seems like progress at least but this error occurred again on the .Login step of my code again. Does this mean the BMC.ARSystem.DLL is not registered properly to .NET? I did reference it in the "Add Reference" window and ran the regasm for it (under Framework not Framework64) and it seemed to setup properly from that. Thanks Peter Lammey ESPN IT Packaging and Automation 860-766-4761 From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Thursday, April 22, 2010 6:03 PM To: arslist@ARSLIST.ORG Subject: Re: .NET API for 7.X ** On Windows, you only have access to the 32-bit Remedy native APIs, and the .NET API uses those DLLs to implement the functionality provided by the .NET API - the .NET API is pretty much a wrapper over the C API and uses the C API to do the actual work. 32-bit DLLs can only be used in a 32-bit process, so the .NET process
Re: .NET API for 7.X
It looks like you're probably missing a DLL, or the path to a DLL the API uses. This is the set of DLLs that I've copied into my bin/Debug directory to get it running: 08/25/2008 08:04 AM 1,163,264 arapi71.dll 12/23/2008 11:25 AM 950,272 arcni71.dll 08/25/2008 08:00 AM77,824 arrpc71.dll 08/25/2008 08:01 AM 167,936 arutl71.dll 12/23/2008 11:25 AM36,352 BMC.arnettoc.dll 12/23/2008 11:25 AM 499,712 BMC.ARSystem.dll 12/23/2008 11:25 AM 301,476 BMC.ARSystem.tlb 12/23/2008 11:25 AM32,768 BMC.ARSystem.Utilities.Common.dll 12/23/2008 11:25 AM 897,861 BMC.ARSystem.xml 12/23/2008 11:25 AM 118,784 BMC.Atrium.dll 12/23/2008 11:25 AM51,682 BMC.Atrium.xml 02/13/2008 02:32 AM 1,581,056 cmdbapi21.dll 10/18/2007 01:01 AM 9,830,400 icudt32.dll 02/06/2007 11:38 AM 696,320 icuinbmc32.dll 02/06/2007 11:37 AM 606,208 icuucbmc32.dll 12/23/2008 11:25 AM 249,856 log4net.dll 12/23/2008 11:25 AM 1,287,495 log4net.xml 08/25/2008 09:16 AM 397,312 rcmn71.dll 04/30/2004 01:40 AM 282,624 vc6-re200l.dll You don't need to copy them all into your run directory, but that makes it easy for development and testing. When deploying, that's also the easiest. However, you could also copy all the native DLLs to any other directory on the system and add that directory to your system Path variable. The .NET DLLs need to be in your application's deployment (run) directory in order to be picked up, since you can't add them to the GAC. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lammey, Peter A. Sent: Friday, April 23, 2010 6:51 AM To: arslist@ARSLIST.ORG Subject: Re: .NET API for 7.X ** OK. I was able to change my project platform from X64 to x86. That might at least tell my VS2008 console application to run in 32 bit mode. However now I get this error: FileNotFoundException was unhandled The specified module could not be found. (Exception from HRESULT: 0x8007007E) Seems like progress at least but this error occurred again on the .Login step of my code again. Does this mean the BMC.ARSystem.DLL is not registered properly to .NET? I did reference it in the "Add Reference" window and ran the regasm for it (under Framework not Framework64) and it seemed to setup properly from that. Thanks Peter Lammey ESPN IT Packaging and Automation 860-766-4761 From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Thursday, April 22, 2010 6:03 PM To: arslist@ARSLIST.ORG Subject: Re: .NET API for 7.X ** On Windows, you only have access to the 32-bit Remedy native APIs, and the .NET API uses those DLLs to implement the functionality provided by the .NET API - the .NET API is pretty much a wrapper over the C API and uses the C API to do the actual work. 32-bit DLLs can only be used in a 32-bit process, so the .NET process that gets executed needs to run in 32-bit mode (that is, with a 32-bit version of the CLR). On a 64-bit OS, it will run a 64-bit version of the CLR by default. When it runs in the 64-bit CLR and then tries to load the 32-bit native DLLs, it generates this error, because you can't use a 32-bit DLL in a 64-bit process. If you are using a full version of Visual Studio (that is, not VS Express), you can set a build option that tells it to add a flag in the application that tells Windows to run it using the 32-bit CLR instead - you need to do that if you want to run it on a 64-bit OS. If you are building it with Visual Studio Express, that option is not available, so the application will always run using the 64-bit CLR on 64-bit machines, generating this error. You might be able to get around that if you're brave enough to figure out all the command line arguments to the compiler necessary to build the application, add the corresponding argument to the list and build it manually instead of within VS... Unfortunately, I'm not certain anymore what the option is, but I think it might be related to architecture or something. I can look it up again, if you're not able to find it. It took me a fair bit of looking before I found the relevant option and discovered that I couldn't use it, because I'm using VS Express... I hope that helps a little. In any case, that's the cause of what you're seeing. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lammey, Peter A. Sent: Thursday, April 22, 2010 3:11 PM To: arslist@ARSLIST.ORG Subject: .NET API for 7.X ** I have downloaded and performed the steps to register and added environment path variables for the .NET API for 7.1 and even tried .NET 7.5 on a Windows 2008 Server. However,
Re: .NET API for 7.X
Peter, Looking at your posting again you mention that you "added the reference to the folder in the System environment path". Do you have a reference to BMC.ARSystem.dll among the references in your VB.NET project? This is the reference you require. Cheers, Jim. -Original Message- From: Jim Ashton [mailto:jim.ash...@ontario.ca] Sent: April 23, 2010 10:40 AM To: arsl...@listserv.rbugs.com Cc: Ashton, Jim (JUS) Subject: Re: .NET API for 7.X No, it's pretty much a straight file copy, wherever you unzip the files to. As long as you've got a directory with all 27 files (as of version 7.1.3128.23911) together, and your reference points to BMC.ARSystem.dll you have the necessary ingredients. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
Re: .NET API for 7.X
No, it's pretty much a straight file copy, wherever you unzip the files to. As long as you've got a directory with all 27 files (as of version 7.1.3128.23911) together, and your reference points to BMC.ARSystem.dll you have the necessary ingredients. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
Re: .NET API for 7.X
When you indicate install, is there an installer package that needs to be run for the netapi71 files? Basically I had copied the folder to the server, added the reference to the folder in the System environment path and added a LIB variable as well. I also did run the regasm command in the framework\v1.1.4322 folder against the BMC.ARSystem.DLL file. Not sure if there is some other registration of the DLL that I am missing. Thanks Peter Lammey ESPN IT Packaging and Automation 860-766-4761 From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ashton, Jim (JUS) Sent: Friday, April 23, 2010 9:58 AM To: arslist@ARSLIST.ORG Subject: Re: .NET API for 7.X ** Peter, When you install the api make sure all the files (some 25 or 30 in all) are in the same directory (eg. c:\netapi71). Set your reference to BMC.ARSystem in this directory. Then try this simple code snippet: Dim oARServer As New BMC.ARSystem.Server 'requires reference be set to BMC.ARSystem assembly (dll in .NET API) oARServer.Login(ServerName, UserID, UserPassword) oARServer.SetServerPort(, 0) 'if specific port is required Assuming that works (and it should) you can take it from there. The use of the environment variable will potentially come into play when you're deploying your application (especially if it is server-side in an ASP.NET context) but the above is all you need to run simple test code within Visual Studio. Cheers, Jim. _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ Please consider the environment before printing this e-mail. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
Re: .NET API for 7.X
Peter, When you install the api make sure all the files (some 25 or 30 in all) are in the same directory (eg. c:\netapi71). Set your reference to BMC.ARSystem in this directory. Then try this simple code snippet: Dim oARServer As New BMC.ARSystem.Server 'requires reference be set to BMC.ARSystem assembly (dll in .NET API) oARServer.Login(ServerName, UserID, UserPassword) oARServer.SetServerPort(, 0) 'if specific port is required Assuming that works (and it should) you can take it from there. The use of the environment variable will potentially come into play when you're deploying your application (especially if it is server-side in an ASP.NET context) but the above is all you need to run simple test code within Visual Studio. Cheers, Jim. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
Re: .NET API for 7.X
OK. I was able to change my project platform from X64 to x86. That might at
least tell my VS2008 console application to run in 32 bit mode.
However now I get this error:
FileNotFoundException was unhandled
The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Seems like progress at least but this error occurred again on the .Login step
of my code again.
Does this mean the BMC.ARSystem.DLL is not registered properly to .NET?
I did reference it in the "Add Reference" window and ran the regasm for it
(under Framework not Framework64) and it seemed to setup properly from that.
Thanks
Peter Lammey
ESPN IT Packaging and Automation
860-766-4761
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor
Sent: Thursday, April 22, 2010 6:03 PM
To: arslist@ARSLIST.ORG
Subject: Re: .NET API for 7.X
**
On Windows, you only have access to the 32-bit Remedy native APIs, and the .NET
API uses those DLLs to implement the functionality provided by the .NET API -
the .NET API is pretty much a wrapper over the C API and uses the C API to do
the actual work. 32-bit DLLs can only be used in a 32-bit process, so the .NET
process that gets executed needs to run in 32-bit mode (that is, with a 32-bit
version of the CLR). On a 64-bit OS, it will run a 64-bit version of the CLR
by default. When it runs in the 64-bit CLR and then tries to load the 32-bit
native DLLs, it generates this error, because you can't use a 32-bit DLL in a
64-bit process.
If you are using a full version of Visual Studio (that is, not VS Express), you
can set a build option that tells it to add a flag in the application that
tells Windows to run it using the 32-bit CLR instead - you need to do that if
you want to run it on a 64-bit OS. If you are building it with Visual Studio
Express, that option is not available, so the application will always run using
the 64-bit CLR on 64-bit machines, generating this error. You might be able to
get around that if you're brave enough to figure out all the command line
arguments to the compiler necessary to build the application, add the
corresponding argument to the list and build it manually instead of within VS...
Unfortunately, I'm not certain anymore what the option is, but I think it might
be related to architecture or something. I can look it up again, if you're not
able to find it. It took me a fair bit of looking before I found the relevant
option and discovered that I couldn't use it, because I'm using VS Express...
I hope that helps a little. In any case, that's the cause of what you're
seeing.
Lyle
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Lammey, Peter A.
Sent: Thursday, April 22, 2010 3:11 PM
To: arslist@ARSLIST.ORG
Subject: .NET API for 7.X
**
I have downloaded and performed the steps to register and added environment
path variables for the .NET API for 7.1 and even tried .NET 7.5 on a Windows
2008 Server.
However, when I tried the API connection to our Remedy BMC 7.01 server using
the code I found on it we keep receiving this error:
{" is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)"}
This error occurs from this .NET code (highlighted in green below:)
Public Function GetRemedyObject(ByVal pRemedyServer As String, ByVal pRemedyUID
As String, ByVal pRemedyPWD As String, ByVal pRemedyPort As String, ByVal
pRemedyRPCProgramNum As String) As BMC.ARSystem.Server
Call objArSystemPub.Login(pRemedyServer, pRemedyUID, pRemedyPWD, "")
Call
objArSystemPub.SetServerPort(Microsoft.VisualBasic.Conversion.Int(pRemedyPort),
Microsoft.VisualBasic.Conversion.Int(pRemedyRPCProgramNum))
GetRemedyObject = objArSystemPub
Return objArSystemPub
End Function
Does anyone in the list have any ideas what might be causing this error?
We have run through and added system environment variables for LIB and PATH and
added to the PATH variable where the API files are (that were downloaded from
the ARAPI75.NET.ZIP) and restarted the server but still no luck.
Is there other steps that need to be followed that will correct this error?
Thanks
Peter Lammey
ESPN IT Packaging and Automation
860-766-4761
_attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies of
the original message.
_attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
Please consider the environment before printing this e-mail.
___
Re: .NET API for 7.X
On Windows, you only have access to the 32-bit Remedy native APIs, and the .NET
API uses those DLLs to implement the functionality provided by the .NET API -
the .NET API is pretty much a wrapper over the C API and uses the C API to do
the actual work. 32-bit DLLs can only be used in a 32-bit process, so the .NET
process that gets executed needs to run in 32-bit mode (that is, with a 32-bit
version of the CLR). On a 64-bit OS, it will run a 64-bit version of the CLR
by default. When it runs in the 64-bit CLR and then tries to load the 32-bit
native DLLs, it generates this error, because you can't use a 32-bit DLL in a
64-bit process.
If you are using a full version of Visual Studio (that is, not VS Express), you
can set a build option that tells it to add a flag in the application that
tells Windows to run it using the 32-bit CLR instead - you need to do that if
you want to run it on a 64-bit OS. If you are building it with Visual Studio
Express, that option is not available, so the application will always run using
the 64-bit CLR on 64-bit machines, generating this error. You might be able to
get around that if you're brave enough to figure out all the command line
arguments to the compiler necessary to build the application, add the
corresponding argument to the list and build it manually instead of within VS...
Unfortunately, I'm not certain anymore what the option is, but I think it might
be related to architecture or something. I can look it up again, if you're not
able to find it. It took me a fair bit of looking before I found the relevant
option and discovered that I couldn't use it, because I'm using VS Express...
I hope that helps a little. In any case, that's the cause of what you're
seeing.
Lyle
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Lammey, Peter A.
Sent: Thursday, April 22, 2010 3:11 PM
To: arslist@ARSLIST.ORG
Subject: .NET API for 7.X
**
I have downloaded and performed the steps to register and added environment
path variables for the .NET API for 7.1 and even tried .NET 7.5 on a Windows
2008 Server.
However, when I tried the API connection to our Remedy BMC 7.01 server using
the code I found on it we keep receiving this error:
{" is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)"}
This error occurs from this .NET code (highlighted in green below:)
Public Function GetRemedyObject(ByVal pRemedyServer As String, ByVal pRemedyUID
As String, ByVal pRemedyPWD As String, ByVal pRemedyPort As String, ByVal
pRemedyRPCProgramNum As String) As BMC.ARSystem.Server
Call objArSystemPub.Login(pRemedyServer, pRemedyUID, pRemedyPWD, "")
Call
objArSystemPub.SetServerPort(Microsoft.VisualBasic.Conversion.Int(pRemedyPort),
Microsoft.VisualBasic.Conversion.Int(pRemedyRPCProgramNum))
GetRemedyObject = objArSystemPub
Return objArSystemPub
End Function
Does anyone in the list have any ideas what might be causing this error?
We have run through and added system environment variables for LIB and PATH and
added to the PATH variable where the API files are (that were downloaded from
the ARAPI75.NET.ZIP) and restarted the server but still no luck.
Is there other steps that need to be followed that will correct this error?
Thanks
Peter Lammey
ESPN IT Packaging and Automation
860-766-4761
_attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
