|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Now I need to do this without breaking ASP.NetVB.Net, and also improve it's functionality. The control is used to collect the user's fingerprint and compare it to a stored copy on the server, and if the match is successful fill some hidden fields with values and call a form submit. We wanted to use web services rather than direct SQL connections as we do now, and to also have the web service URL set dynamically. We built the project as a Windows Control (DLL) class with COM Class and COM Visible set to True. We were able to get the control to load in IE, but due to the need to interface with the local USB fingerprint device we had to list the web site as Trusted and elevate the Trusted Zone to perform no security checks (Problem #1). The class required a couple of DLL files to function properly, and as expected we were able to put them in the same folder as the class DLL file and they were downloaded automatically. The problem was the App.Config file, it never would download. (Problem #2) We recently figured out that apparently a DLL can't make use of App.Config, but the calling app can. This explained seeing the client attempt to download iexplore.exe.config in the web logs. To make matters worse, it wasn't attempting to download the file from the location of the class DLL, but rather from the root of the web site and from /bin folder. (Problem #3) So we renamed the App.Config file and placed it in the root. It still would not download, this time with 403 Errors which we determined were the ASP.Net interpreter trying to process the file rather than allow direct access. (Problem #4) We decided to remove the parsing of .config files from the configuration of the root web app, which finally allowed everything to execute properly. But now, if we had any web.config files in the root app, they would be open to being freely downloaded, and might not even work at all (Problem #5) I just know there has to be a better way to do this. I cannot believe that it's this difficult with .Net to duplicate and improve on the functionality we had using VB6. Perhaps someone with experience in things such as this will step forward and point us in another direction. Thanks, Patrick Bates "Patrick Bates" <pbates@spam.me.notsmartbuys.com> wrote in message <<clipped>>news:OagDH37mGHA.2056@TK2MSFTNGP05.phx.gbl... > I've been struggling for two weeks now to duplicate a VB6 ActiveX control > in VB.Net, and also improve it's functionality. > I just know there has to be a better way to do this. I cannot believe You didn't just move from VB6 to VB.Net, you also moved from rich client to > that it's this difficult with .Net to duplicate and improve on the > functionality we had using VB6. Perhaps someone with experience in things > such as this will step forward and point us in another direction. > > Thanks, > Patrick Bates > > thin client. Since you are accessing a local device that is installed on the client PC, I am wondering about the decision to switch to thin client. Why not remain a rich client with one-click deployment? That will allow you to update your client software as needed and not to deal with all these issues. In other words, you don't have a language problem or a platform problem... you have an architecture problem. Your previous architecture worked. Why did you leave? -- --- Nick Malik [Microsoft] MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik Disclaimer: Opinions expressed in this forum are my own, and not representative of my employer. I do not answer questions on behalf of my employer. I'm just a programmer helping programmers. -- I second Nick's comment. And that's I was thinking when reading your post
and before reading Nick's reply. Show quote "Patrick Bates" <pbates@spam.me.notsmartbuys.com> wrote in message news:OagDH37mGHA.2056@TK2MSFTNGP05.phx.gbl... > I've been struggling for two weeks now to duplicate a VB6 ActiveX control > in VB.Net, and also improve it's functionality. The control is used to > collect the user's fingerprint and compare it to a stored copy on the > server, and if the match is successful fill some hidden fields with values > and call a form submit. We wanted to use web services rather than direct > SQL connections as we do now, and to also have the web service URL set > dynamically. > > We built the project as a Windows Control (DLL) class with COM Class and > COM Visible set to True. We were able to get the control to load in IE, > but due to the need to interface with the local USB fingerprint device we > had to list the web site as Trusted and elevate the Trusted Zone to > perform no security checks (Problem #1). > > The class required a couple of DLL files to function properly, and as > expected we were able to put them in the same folder as the class DLL file > and they were downloaded automatically. The problem was the App.Config > file, it never would download. (Problem #2) We recently figured out that > apparently a DLL can't make use of App.Config, but the calling app can. > This explained seeing the client attempt to download iexplore.exe.config > in the web logs. To make matters worse, it wasn't attempting to download > the file from the location of the class DLL, but rather from the root of > the web site and from /bin folder. (Problem #3) > > So we renamed the App.Config file and placed it in the root. It still > would not download, this time with 403 Errors which we determined were the > ASP.Net interpreter trying to process the file rather than allow direct > access. (Problem #4) We decided to remove the parsing of .config files > from the configuration of the root web app, which finally allowed > everything to execute properly. But now, if we had any web.config files > in the root app, they would be open to being freely downloaded, and might > not even work at all (Problem #5) > > I just know there has to be a better way to do this. I cannot believe > that it's this difficult with .Net to duplicate and improve on the > functionality we had using VB6. Perhaps someone with experience in things > such as this will step forward and point us in another direction. > > Thanks, > Patrick Bates > >  |
|||||||||||||||||||||||
Other interesting topics