By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,602 Members | 1,457 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,602 IT Pros & Developers. It's quick & easy.

Assembly on shared drive just doesn't work???

P: n/a
I have an assembly on a shared LAN drive. On my developer machine, I give
that assembly full trust from the .NET wizard. It works fine. I go to a
user machine on the LAN, map to the shared drive, give full trust on that
machine but the assembly doesn't fully work. No errors. The assembly post
data from MS Access to a website. The posting part doesn't work. The
firewall was turned off and still nothing.

Any ideas?

Thanks,
Brett
Nov 17 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
hi,

do you any logging in the program? did you check the event log?

Does the user machine has access to the server?
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Brett" <no@spam.com> wrote in message
news:uq**************@TK2MSFTNGP15.phx.gbl...
I have an assembly on a shared LAN drive. On my developer machine, I give
that assembly full trust from the .NET wizard. It works fine. I go to a
user machine on the LAN, map to the shared drive, give full trust on that
machine but the assembly doesn't fully work. No errors. The assembly post
data from MS Access to a website. The posting part doesn't work. The
firewall was turned off and still nothing.

Any ideas?

Thanks,
Brett

Nov 17 '05 #2

P: n/a
> do you any logging in the program?
There isn't any logging. What exactly could I log to help out?
did you check the event log? There isn't anything entered that looks as though it relates to this
problem.
Does the user machine has access to the server? It is listed in his Windows Explorer and a map was successfully made to a
path on that server. This is where the program is executed from.

The program writes to a text file on the network drive. Then it post data
from an MS Access database to a website. It does successfully write to the
text file on the user machine. If it were a security issue, this shouldn't
happen right?

Any other suggestions are welcome.

Thanks,
Brett

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:e3**************@TK2MSFTNGP15.phx.gbl... hi,

do you any logging in the program? did you check the event log?

Does the user machine has access to the server?
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Brett" <no@spam.com> wrote in message
news:uq**************@TK2MSFTNGP15.phx.gbl...
I have an assembly on a shared LAN drive. On my developer machine, I give
that assembly full trust from the .NET wizard. It works fine. I go to a
user machine on the LAN, map to the shared drive, give full trust on that
machine but the assembly doesn't fully work. No errors. The assembly
post data from MS Access to a website. The posting part doesn't work.
The firewall was turned off and still nothing.

Any ideas?

Thanks,
Brett


Nov 17 '05 #3

P: n/a

"Brett" <no@spam.com> wrote in message
news:uQ**************@TK2MSFTNGP14.phx.gbl...
do you any logging in the program? There isn't any logging. What exactly could I log to help out?


Well you could know if you get an exception you will know the line where it
occured. Probably now you are just catch ing it and doing nothing.
The program writes to a text file on the network drive. Then it post data
from an MS Access database to a website. It does successfully write to
the text file on the user machine. If it were a security issue, this
shouldn't happen right?


How come it does not give you any exception or errors?

That's why my suggestion about logging

Also are you sure that the machine has Jet installed?

Are you using oledb or ODBC ?

Do you have JET installed?
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
Nov 17 '05 #4

P: n/a
Brett,

Just to clarify, you are still running the .exe on your user machine...
you're just loading it from a shared drive, right? It works when you
run it from a local copy, but not when you invoke the same executable
on the same machine, but loading it from a shared drive. Is this
accurate?

Nov 17 '05 #5

P: n/a

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:Of**************@tk2msftngp13.phx.gbl...

"Brett" <no@spam.com> wrote in message
news:uQ**************@TK2MSFTNGP14.phx.gbl...
do you any logging in the program? There isn't any logging. What exactly could I log to help out?


Well you could know if you get an exception you will know the line where
it occured. Probably now you are just catch ing it and doing nothing.
The program writes to a text file on the network drive. Then it post
data from an MS Access database to a website. It does successfully write
to the text file on the user machine. If it were a security issue, this
shouldn't happen right?


How come it does not give you any exception or errors?

That's why my suggestion about logging

Also are you sure that the machine has Jet installed?

Are you using oledb or ODBC ?

Do you have JET installed?


I'm using oledb. How can I be sure JET is installed?



cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

Nov 17 '05 #6

P: n/a

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
Brett,

Just to clarify, you are still running the .exe on your user machine...
you're just loading it from a shared drive, right? It works when you
run it from a local copy, but not when you invoke the same executable
on the same machine, but loading it from a shared drive. Is this
accurate?


No. The EXE is on a server. Two machines map a J drive to the server. My
developer machine executes the EXE fine. The user machine doesn't. No
errors. The prog writes to a text file but it will not post MS Access data
to a website. All of that works on my developer machine.

Thanks,
Brett
Nov 17 '05 #7

P: n/a

"Brett" <no@spam.com> wrote in message
news:e%****************@TK2MSFTNGP15.phx.gbl...

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
Brett,

Just to clarify, you are still running the .exe on your user machine...
you're just loading it from a shared drive, right? It works when you
run it from a local copy, but not when you invoke the same executable
on the same machine, but loading it from a shared drive. Is this
accurate?


No. The EXE is on a server. Two machines map a J drive to the server.
My developer machine executes the EXE fine. The user machine doesn't. No
errors. The prog writes to a text file but it will not post MS Access
data to a website. All of that works on my developer machine.

Thanks,
Brett


Yes, the exe is on the share but it runs on the client's machine. As Ignacio
said, you have to make sure all components to access the Access files
(loacted on the same share?) are installed on the client.
As there's no exception thrown when trying to open the DB, I suppose that
accessing the DB is not an issue, remains the question what you mean exactly
with post to the webserver, and where is the server located (same as the
exposing the share?).
What kind of application is this (console, Windows Forms?).

Willy.

Nov 17 '05 #8

P: n/a

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:OS*************@TK2MSFTNGP14.phx.gbl...

"Brett" <no@spam.com> wrote in message
news:e%****************@TK2MSFTNGP15.phx.gbl...

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
Brett,

Just to clarify, you are still running the .exe on your user machine...
you're just loading it from a shared drive, right? It works when you
run it from a local copy, but not when you invoke the same executable
on the same machine, but loading it from a shared drive. Is this
accurate?

No. The EXE is on a server. Two machines map a J drive to the server.
My developer machine executes the EXE fine. The user machine doesn't.
No errors. The prog writes to a text file but it will not post MS Access
data to a website. All of that works on my developer machine.

Thanks,
Brett


Yes, the exe is on the share but it runs on the client's machine. As
Ignacio said, you have to make sure all components to access the Access
files (loacted on the same share?) are installed on the client.
As there's no exception thrown when trying to open the DB, I suppose that
accessing the DB is not an issue, remains the question what you mean
exactly with post to the webserver, and where is the server located (same
as the exposing the share?).


The DB, text file and EXE are all in the same directory on a shared drive.
DB writes an ID # to the text file. The EXE reads an ID # from the text
file. It uses this ID # to access a table in the DB and writes that to a
CSV file. The CSV is then POSTed to remote website. A FORM POST is used via
httpResponseArray = myWebClient.UploadFile(strPost, "POST", FileName)
What kind of application is this (console, Windows Forms?). WinForm.

Willy.


Nov 17 '05 #9

P: n/a

"Brett" <no@spam.com> wrote in message
news:e0**************@TK2MSFTNGP14.phx.gbl...

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:OS*************@TK2MSFTNGP14.phx.gbl...

"Brett" <no@spam.com> wrote in message
news:e%****************@TK2MSFTNGP15.phx.gbl...

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
Brett,

Just to clarify, you are still running the .exe on your user machine...
you're just loading it from a shared drive, right? It works when you
run it from a local copy, but not when you invoke the same executable
on the same machine, but loading it from a shared drive. Is this
accurate?
No. The EXE is on a server. Two machines map a J drive to the server.
My developer machine executes the EXE fine. The user machine doesn't.
No errors. The prog writes to a text file but it will not post MS
Access data to a website. All of that works on my developer machine.

Thanks,
Brett


Yes, the exe is on the share but it runs on the client's machine. As
Ignacio said, you have to make sure all components to access the Access
files (loacted on the same share?) are installed on the client.
As there's no exception thrown when trying to open the DB, I suppose that
accessing the DB is not an issue, remains the question what you mean
exactly with post to the webserver, and where is the server located (same
as the exposing the share?).


The DB, text file and EXE are all in the same directory on a shared drive.
DB writes an ID # to the text file. The EXE reads an ID # from the text
file. It uses this ID # to access a table in the DB and writes that to a
CSV file. The CSV is then POSTed to remote website. A FORM POST is used
via
httpResponseArray = myWebClient.UploadFile(strPost, "POST", FileName)
What kind of application is this (console, Windows Forms?).

WinForm.


Is the CSV file created? If it is, you might have a security issue when
posting to the webserver, again this should throw an exception unless you
swallow them :).

Willy.
Nov 17 '05 #10

P: n/a

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:OK****************@tk2msftngp13.phx.gbl...

"Brett" <no@spam.com> wrote in message
news:e0**************@TK2MSFTNGP14.phx.gbl...

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:OS*************@TK2MSFTNGP14.phx.gbl...

"Brett" <no@spam.com> wrote in message
news:e%****************@TK2MSFTNGP15.phx.gbl...

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
> Brett,
>
> Just to clarify, you are still running the .exe on your user
> machine...
> you're just loading it from a shared drive, right? It works when you
> run it from a local copy, but not when you invoke the same executable
> on the same machine, but loading it from a shared drive. Is this
> accurate?
>

No. The EXE is on a server. Two machines map a J drive to the server.
My developer machine executes the EXE fine. The user machine doesn't.
No errors. The prog writes to a text file but it will not post MS
Access data to a website. All of that works on my developer machine.

Thanks,
Brett
Yes, the exe is on the share but it runs on the client's machine. As
Ignacio said, you have to make sure all components to access the Access
files (loacted on the same share?) are installed on the client.
As there's no exception thrown when trying to open the DB, I suppose
that accessing the DB is not an issue, remains the question what you
mean exactly with post to the webserver, and where is the server located
(same as the exposing the share?).


The DB, text file and EXE are all in the same directory on a shared
drive. DB writes an ID # to the text file. The EXE reads an ID # from
the text file. It uses this ID # to access a table in the DB and writes
that to a CSV file. The CSV is then POSTed to remote website. A FORM
POST is used via
httpResponseArray = myWebClient.UploadFile(strPost, "POST", FileName)
What kind of application is this (console, Windows Forms?).

WinForm.


Is the CSV file created? If it is, you might have a security issue when
posting to the webserver, again this should throw an exception unless you
swallow them :).

Willy.


I can't run the app just yet but what type of security issue on that one
machine may exists?

Thanks,
Brett
Nov 17 '05 #11

P: n/a
Hi,

I'm using oledb. How can I be sure JET is installed?


IIRC the newer versions of MDAC does not include the JET provider, you can
download it from MS site.

Now, I would implement a logging of each steps, somewhere it has to fail and
give you an exception or an error code. It seems to be in the POST upload,
as you said that it created the file correctly.
Does the web require auth?
What if you just do a WebRequest , just to see if you have access to it

Still, I think you are catching an exception somewhere and doing nothing
about it.

cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
Nov 17 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.