Riddle Me This

  • Thread starter Thread starter pbd22
  • Start date Start date
Willy -

Sorry for the semantic misfire.

I mean, the service works in Debug mode.
When I put it in Release mode and install
it using the installutil and then start it in
services, it fails.

Works in the IDE, fails when started from
"Services".

I have not tried to install the debug version
with installutil, that didn't occur to me. I'll
try that now.

Peter
 
Willy -

Sorry for the semantic misfire.

I mean, the service works in Debug mode.
When I put it in Release mode and install
it using the installutil and then start it in
services, it fails.

Works in the IDE, fails when started from
"Services".

I have not tried to install the debug version
with installutil, that didn't occur to me. I'll
try that now.

Peter
 
OK.

Debug and Release do not work after installutil from the Services
window.
Debug works from the IDE.

The service is Local System account in Services view.
The service does not have the "Allow service to interact with desktop"
checked.

The ProjectInstaller.cs file has the following code:

this.serviceProcessInstaller1.Account =
System.ServiceProcess.ServiceAccount.LocalSystem;
this.serviceProcessInstaller1.Password = null;
this.serviceProcessInstaller1.Username = null;

The properties of the EXE file are:

Administrators
LOCAL SERVICE
(My Login)
Power Users
SERVICE
SYSTEM
Users

The containing folder's Properties are:
Administrators
CREATOR OWNER
LOCAL SERVICE
(My Login)
SYSTEM
Users

Everything has been granted "Full Control" for tire-kicking.

Debug efforts:

I have set the following in my Service1.cs file:

InitializeComponent();

if (!
System.Diagnostics.EventLog.SourceExists("MyService"))
{
System.Diagnostics.EventLog.CreateEventSource(
"MyService", "MyLog");
}

eventLog1.Source = "MyService";
eventLog1.Log = "MyLog";

And, of course, the following try/catch block where appropriate:

catch (Exception e)
{
eventLog1.WriteEntry("Error with service:" +
e.Message, EventLogEntryType.Error);
return;
}

Finally, I can see the process start and stop when running the code
from the IDE.
I CANNOT see the process start when running the service from windows
(after installutil).

I appreciate your help.
Peter
 
pbd22 said:
OK.

Debug and Release do not work after installutil from the Services
window.
Debug works from the IDE.

The service is Local System account in Services view.
The service does not have the "Allow service to interact with desktop"
checked.

The ProjectInstaller.cs file has the following code:

this.serviceProcessInstaller1.Account =
System.ServiceProcess.ServiceAccount.LocalSystem;
this.serviceProcessInstaller1.Password = null;
this.serviceProcessInstaller1.Username = null;

The properties of the EXE file are:

Administrators
LOCAL SERVICE
(My Login)
Power Users
SERVICE
SYSTEM
Users

The containing folder's Properties are:
Administrators
CREATOR OWNER
LOCAL SERVICE
(My Login)
SYSTEM
Users

Everything has been granted "Full Control" for tire-kicking.

Debug efforts:

I have set the following in my Service1.cs file:

InitializeComponent();

if (!
System.Diagnostics.EventLog.SourceExists("MyService"))
{
System.Diagnostics.EventLog.CreateEventSource(
"MyService", "MyLog");
}

eventLog1.Source = "MyService";
eventLog1.Log = "MyLog";

And, of course, the following try/catch block where appropriate:

catch (Exception e)
{
eventLog1.WriteEntry("Error with service:" +
e.Message, EventLogEntryType.Error);
return;
}

Finally, I can see the process start and stop when running the code
from the IDE.
I CANNOT see the process start when running the service from windows
(after installutil).

I appreciate your help.
Peter



So, you have the service correctly registered, but when you try to start the
service from the service applet (or from the command line using net
start...), the service doesn't start at all. What does the eventlog tell
you? And what do you have in your OnStart method. Are you sure you start a
thread to run the service from within your OnStart or from within a method
called from OnStart????


Willy.
 
Thanks for your reply Willy.

Seems I am articulating myself poorly today.
So, you have the service correctly registered, but when you try to start the
service from the service applet (or from the command line using net
start...), the service doesn't start at all.

The service DOES START. In fact (annoyingly) the Event Log throws
absolutely
no errors. It starts, it runs, and it shuts down when i tell it to. I
even wrote a
custom Event Log that produces no information.

When I say "it doesn't work", I am talking about the exe.

For what it is worth, here is the OnStart method:

protected override void OnStart(string[] args)
{
ventLog1.WriteEntry("Service started successfully.",
EventLogEntryType.Information);
new Thread(new ThreadStart(InitService)).Start();
}
 
pbd22 said:
Thanks for your reply Willy.

Seems I am articulating myself poorly today.
So, you have the service correctly registered, but when you try to start
the
service from the service applet (or from the command line using net
start...), the service doesn't start at all.

The service DOES START. In fact (annoyingly) the Event Log throws
absolutely
no errors. It starts, it runs, and it shuts down when i tell it to. I
even wrote a
custom Event Log that produces no information.

When I say "it doesn't work", I am talking about the exe.

For what it is worth, here is the OnStart method:

protected override void OnStart(string[] args)
{
ventLog1.WriteEntry("Service started successfully.",
EventLogEntryType.Information);
new Thread(new ThreadStart(InitService)).Start();
}



Ok, so far so good ;-)
What makes you think the exec is not started, is the process not visible in
the process list? If not, how does the program signals success/failure to
the parent process (the service in this case)?
How do you start the exec, show us the code that start the exec.
Give also some details about the exec, type of program, what security and
user context does it require to run in, does it expect a user profile to be
loaded?


Willy.
 
What makes you think the exec is not started, is the process not visible in
the process list?

That is right.
If not, how does the program signals success/failure to
the parent process (the service in this case)?

Well, its a queue. There is no return value. We know the proccess
takes
about 2 seconds. So, it should run accordingly. If one is running when
the
other wants to run, it queues until the first one is done.
How do you start the exec, show us the code that start the exec.

Here is the code:

if (filetype = true)
{

try
{

ProcessStartInfo psi = new
ProcessStartInfo(exepath, args);

lock (_objLock)
{
if (_fProcessRunning)
{
_procq.Enqueue(psi);
psi = null;
}

_fProcessRunning = true;
}

if (psi != null)
{
StartAProcess(psi);
}

}
catch (Exception e)
{
eventLog1.WriteEntry("Error parsing file:" +
e.Message, EventLogEntryType.Error);
return;
}

}

}

void StartAProcess(ProcessStartInfo psi)
{

try
{

Process process = new Process();

process.StartInfo = psi;
process.EnableRaisingEvents = true;

process.Exited += ProcessExitedHandler;

process.Start();
}
catch (Exception e)
{
eventLog1.WriteEntry("Error with StartAProcess
method:" + e.Message, EventLogEntryType.Error);
return;
}

}

void ProcessExitedHandler(object sender, EventArgs e)
{

ProcessStartInfo psi = null;

lock (_objLock)
{
if (_procq.Count > 0)
{
psi = _procq.Dequeue();
}
else
{
_fProcessRunning = false;
}
}

if (psi != null)
{
StartAProcess(psi);
}

}

Give also some details about the exec, type of program,

VB6 application. That has been stripped of all UI "stuff".
what security and user context does it require to run in,

Can you tell me how I would find that out?
does it expect a user profile to be loaded?

No. It simply does the following:

Opens a file.
Extracts metadata.
Writes metadata to text file.
Closes file.

Thanks a ton!
Peter
 
More info on the exe project:

Type:
Standard EXE

Startup Object:
Form 1

Upgrade ActiveX Controls:
checked

References:

Visual Basic for Applications
Visual Basic runtime objects and procedures
Visual Basic objects and procedures
OLE Automation
COM DLL
 
pbd22 said:
That is right.


Well, its a queue. There is no return value. We know the proccess
takes
about 2 seconds. So, it should run accordingly. If one is running when
the
other wants to run, it queues until the first one is done.


Here is the code:

if (filetype = true)
{

try
{

ProcessStartInfo psi = new
ProcessStartInfo(exepath, args);

lock (_objLock)
{
if (_fProcessRunning)
{
_procq.Enqueue(psi);
psi = null;
}

_fProcessRunning = true;
}

if (psi != null)
{
StartAProcess(psi);
}

}
catch (Exception e)
{
eventLog1.WriteEntry("Error parsing file:" +
e.Message, EventLogEntryType.Error);
return;
}

}

}

void StartAProcess(ProcessStartInfo psi)
{

try
{

Process process = new Process();

process.StartInfo = psi;
process.EnableRaisingEvents = true;

process.Exited += ProcessExitedHandler;

process.Start();
}
catch (Exception e)
{
eventLog1.WriteEntry("Error with StartAProcess
method:" + e.Message, EventLogEntryType.Error);
return;
}

}

void ProcessExitedHandler(object sender, EventArgs e)
{

ProcessStartInfo psi = null;

lock (_objLock)
{
if (_procq.Count > 0)
{
psi = _procq.Dequeue();
}
else
{
_fProcessRunning = false;
}
}

if (psi != null)
{
StartAProcess(psi);
}

}



VB6 application. That has been stripped of all UI "stuff".


Can you tell me how I would find that out?


No. It simply does the following:

Opens a file.
Extracts metadata.
Writes metadata to text file.
Closes file.

Thanks a ton!
Peter



What I wan is the Service code that initiate a process start, that is the
call site of the piece of code you posted above (starting with if (filetype
= true), which is not the start of a method I suppose. I also would suggest
you to add some logging stuff to the above code.
Also, you can't strip all UI stuff from VB6 application,a VB6 application
is by definition a windows application, which makes it hard to get started
from a Windows Service.

Willy.
 
Thanks again Willy.

I sent you the windows service code to your private email address.
You will see the calling method there (I sent a description in my
email).

Feel free to continue the thread by responding here.

THanks again for all your help!
Peter
 
pbd22 said:
Thank everybody for your suggestions.

The purpose of the EXE is to open a file, read its metadata,
create a text file, move the metadata to the text file,
close the file, exit.

So, it sounds to me like this very much uses the desktop!

No, that doesn't sound like it uses the desktop. You could compile it as a
dll and reference it in the usual way.

Michael
 
pbd22 said:
Well, this was the thinking behind the exe in the first place.
We wanted the DLL to be called from the service but the COM object
is STA and the service (C#) is MTA and we couldnt come up with a
reliable way to handle the differences. Declaring the service as
[STAThread] did not do the trick nor did other programmatic tricks.

That answers my question above. I'm no expert on threading, perhaps someone
can suggest a solution.

But, why does this dll need to be in VB6, it doesn't sound like it's all
that complicated and being that it has no GUI wouldn't it be easy to
translate to C#? Or if you need it to work from vb6 and c# you could write
it in C++ and wack it in a dll.

Michael
 
Thanks Mike.

Well, if you want to go to the core, the whole problem started
with how VB6 and C# handle events. IN the VB6 project, we
had:

Dim WithEvents meta As VB6DLL

which was simple enough.

When I tried translating this bit of code into my C# Windows Service
I started to realize how different threading is in VB6 and the .NET
CLR.
We couldn't make events that happened in the VB6 project, happen in
the C#
windows service.

So, we stuck with the VB6 exe and are now calling it as an
external process. Ugly, but it I feel reasonably close to a solution
here vs. revisiting dusty computer science books to wrap my
mind around the threading differences.

I like your idea about turning this VB6 project into a C# (or C++)
Class LIbrary.
But I will, however, still need to call a VB6 DLL for event handling.
So,
I am wondering if I am going to run into the same threading (STA/MTA)
problem I had when we tried to do this before. The core of this
problem
is a VB6 eventhandler translated into a C# (or C++) project. I don't
know enough
about DLL creation, but it sounds to me that the problem should be the
same (whether its a .NET DLL or .NET windows service).

I am all ears if somebody has a clear understanding of the VB6/.NET
CLR
threading differences and how to translate VB6 event handling into
my .NET
project. But, because I am already out of time and feel like we are
very close with
the external exe, I think i'd prefer to follow the exe road unless
somebody out
there can provide an excellent threading solution (with clear examples
that are
directly related to my project).

Again, as always, I really appreciate everybody's help!

Peter
 
pbd22 said:
When I tried translating this bit of code into my C# Windows Service
I started to realize how different threading is in VB6 and the .NET
CLR.
We couldn't make events that happened in the VB6 project, happen in
the C#
windows service.

I'm not sure if I follow you 100% here but I'm presuming you're talking
about problems with C# interacting with VB6? My question was is it possible
to translate ALL code to C#.

Regards,
Michael
 
Sorry Mike,

I thought you were talking about the exe, but I now
realize you were talking about the exe and the DLL
it references. It is absolutely possible to move the
EXE to C# - it is only a Form_Load and two supporting
subroutines. The DLL it references is some insane
DLL in C (not C++) that we hired a contractor for. I
think it makes extensive use of DirectShow. I know
very little about it, only that it does what it is supposed
to do.

Peter
 
pbd22 said:
Sorry Mike,

I thought you were talking about the exe, but I now
realize you were talking about the exe and the DLL
it references. It is absolutely possible to move the
EXE to C# - it is only a Form_Load and two supporting
subroutines. The DLL it references is some insane
DLL in C (not C++) that we hired a contractor for. I
think it makes extensive use of DirectShow. I know
very little about it, only that it does what it is supposed
to do.

So let me get this straight, you've got a service in C# that is calling an
exe written in VB6 than references a dll written in C that references
directShow a lot. Is that about right? Is the dll written in C a com dll or
a standard dll.

Michael
 
So let me get this straight, you've got a service in C# that is calling an
exe written in VB6 than references a dll written in C that references
directShow a lot. Is that about right? Is the dll written in C a com dll or
a standard dll.

Michael

Yes, that is all correct.
The DLL is COM.
 
Yikes; good luck getting that lot to play ball together... I'm not at
all convinced that using DirectShow in a service is a very good
idea... and all those layers? It may be time to consider calling into
managed DirectX instead... but even then I'm not sure that a service
is going to cut it... remember that the destop integration is disabled
from Vista etc...

Marc
 
pbd22 said:
Yes, that is all correct.
The DLL is COM.


Your VB6 application runs in the same context of the Windows Service,
services should never assume an interactive logon session to be present and
should never interact with the desktop, but this is exactly what you are
expecting. VB6 applications and the COM components used by this application
aren't designed to be used in such context. You will never get it right.

Willy.
 
Willy,

I sent you relevant code to your email over the weekend.
Please tell me what I have to do to "get it right". This
has been a royal headache and I am really stumped.

Peter
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top