468,512 Members | 1,633 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,512 developers. It's quick & easy.

C# DLL - Used in VB Project - Certificate Store gathering certs for use in httpwebrequest

Joe
Hello,
I'm currently using a C# class library which is also
converted quickly to a console app by adding a MAIN and adjusting the
building configuration. I'm using this page as a reference to the
code. http://support.microsoft.com/kb/895971 .

I am using the CryptoAPI calls instead of a *.cer file. The only
reason i'm using this method instead is because now a large project of
mine no longer will work properly when using an exported cer file.
This is your typical hit a webservice with a certificate and process
some XML. I put together the C# classlibrary page and created a main
to run some tests on the c# code. Everything works Perfect when
running the console app and obtaining the certificate from the store
and then hitting the URL. BUT when i include the DLL that was created
from the c# class library in a VB project and attempt to run the exact
same code it fails. The line that is causing all the problems is the
function from the crypt32.dll.

currentCertContext = CertEnumCertificatesInStore(storeHandle,
(IntPtr)0);

This line in my C# console app works just fine and returns a HANDLE as
its supposed to thats not zero. But when running thru the exact same
code but thru the VB project calling the objects from the DLL the
currentCertContext is always 0. Causing this process to not gather
any certificates. I don't get how the code alone in its own console
app works just fine but when its included as a DLL in a vb site it
doesn't work. Has anyone ran into anything like this ever? Or heard
anything about this occuring? I can provide more information if
needed. As i debug and walk through the VB app it goes into the DLL
(even opens up the C# page and goes thru the same process) But that
one line isn't producing a proper intptr handle. Any information
would be greatly appreciated.

May 10 '07 #1
1 5651
Joe
On May 10, 1:01 pm, Joe <eterna...@gmail.comwrote:
Hello,
I'm currently using a C# class library which is also
converted quickly to a console app by adding a MAIN and adjusting the
building configuration. I'm using this page as a reference to the
code.http://support.microsoft.com/kb/895971.

I am using the CryptoAPI calls instead of a *.cer file. The only
reason i'm using this method instead is because now a large project of
mine no longer will work properly when using an exported cer file.
This is your typical hit a webservice with a certificate and process
some XML. I put together the C# classlibrary page and created a main
to run some tests on the c# code. Everything works Perfect when
running the console app and obtaining the certificate from the store
and then hitting the URL. BUT when i include the DLL that was created
from the c# class library in a VB project and attempt to run the exact
same code it fails. The line that is causing all the problems is the
function from the crypt32.dll.

currentCertContext = CertEnumCertificatesInStore(storeHandle,
(IntPtr)0);

This line in my C# console app works just fine and returns a HANDLE as
its supposed to thats not zero. But when running thru the exact same
code but thru the VB project calling the objects from the DLL the
currentCertContext is always 0. Causing this process to not gather
any certificates. I don't get how the code alone in its own console
app works just fine but when its included as a DLL in a vb site it
doesn't work. Has anyone ran into anything like this ever? Or heard
anything about this occuring? I can provide more information if
needed. As i debug and walk through the VB app it goes into the DLL
(even opens up the C# page and goes thru the same process) But that
one line isn't producing a proper intptr handle. Any information
would be greatly appreciated.
UPDATE****************
I've ran into a sticky situation. I currently have a ASP.NET
web project, this project uses webservices to receive XML from various
locations. One of the locations requires a x509 certificate in order
for it to work properly. All was good until they sent us a new
certificate two weeks ago. Now using the export *.cer method I can no
longer hit there webservice. They tell me that anything thats going
wrong is on my end. After much playing around with it, I decided to
try the CryptoAPI way instead, which would be just to hit the actual
certificate store and gather all the certs in a collection and pull
the one that i need directly from it and apply it to the
httpwebrequest object. I wrote up a small C# console app, this app is
very basic its just going to the store gathering the certs then
applying the cert to a webrequest object then hitting the URL. As a
console app this works just fine. I adjusted my console app to become
a compiled DLL. I then add a reference to my VB project of that DLL.
But now I cannot grab any certificates from any store. I believe this
has to do with the fact that the console app is running under a
different user context than my vb.net web project. My question would
be how can get my ASP.NET web project to actually have access to the
certificate store? I've followed along on http://msdn2.microsoft.com/en-us/library/aa302408.aspx
this page numerous times giving permission to the ASPNET/
NetworkService/Administrator users to that particular certificate.
but nothing will access it. Its currently residing on both my
certificates of my local user as well as the certificates of my local
computer. Is there anyway to get this to work properly? The code
that is being based off of is from the microsoft page that explains
the two ways to access the certificate. The *.cer way and the
CryptoAPI way. Any information would be greatly appreciated.

May 10 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Jonathan Wax | last post: by
reply views Thread by NRao | last post: by
reply views Thread by Jojo1771 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.