http://support.digipede.net/community Digipede Technologies Community forum. en Mon, 06 Sep 2010 10:33:45 GMT vBulletin 60 http://support.digipede.net/community/images/misc/rss.jpg http://support.digipede.net/community http://support.digipede.net/community/showthread.php?t=256&goto=newpost Fri, 13 Aug 2010 19:37:10 GMT Hello, I am having a problem receiving the debug files in the temporary directory created under c:/documents and settings/all users/application data/digipede/agent/. The primary program assets are placed there, but the files that cannot be discovered through reflection do not arrive. Therefore I... Hello,

I am having a problem receiving the debug files in the temporary directory created under c:/documents and settings/all users/application data/digipede/agent/. The primary program assets are placed there, but the files that cannot be discovered through reflection do not arrive. Therefore I cannot debug into the app on the Agent using the Digipede SDK automation in VS9.

Here's the story:

To catch a nasty little problem with serialization of a large data structure, I have reconfigured my dev environment to conform with the 'traditional' digipede SDK situation where VS9 is installed on an agent.

I have a pretty robust 'dispatcher' assembly that creates and configures and submits Jobs and Tasks. This assembly also programmatically configures a JobTemplate for each Job based on config file values that are merged with config values received from a web service call that intitates the request for a Job to be dispatched to the Digipede network.

Among several things that are managed in this process are the debug files and additional files that are needed for operation of the code but which may not be strictly available to .NET reflection during an inspection of assembly meta-data contained in the primary dll's.

So I'm adding the necessary files as file-def's to the JobTemplate. And I'm setting the AutoIncludeDebugFiles property of the Digipede Client object that initiates the submission.

I have examined the contents of the FileDef's collection by dumping it to the log. The first 22 entries list the dll's that can be discovered by reflection, some of them listed more than once. The local names are the names of the DLL's. and the remote names include the path to the file in the .NET 2.0 Temporary ASP.NET folder under the folder assigned to the WCF Web Service bin folder where the application is installed by my web installation project.

Afer those entries, my filedef's that are inserted by means of code appear. These files include the PDB's and the log4net config file, for example.

These filedef's have the local name and remote name that is prepended by the path I have stipulated for the Agent RunDirectory where my installer places ALL the necessary application assets. I also stipulate the local path to this RunDirectory to the Job Template in another setting.

Based on looking at this information, I believe my understanding of how these features operate is incomplete or incorrect.

What has been working is that the Agent's are clearly recieving ALL the application assets necessary to run the application, even though the 22 entries in the filedef's collection that are created by Digipede are not the necessary and complete list.

To me this means that the instruction to the Job Template to go to the RunDirectory location and get the assets is operating correctly, except that the PDB's are not being moved, despite the AutoIncludeDebugFiles setting.

Also, it appears that the filedef entries I am adding programmatically with the prepended path to where they are stored on the digipede server, these files are not being moved anywhere.

In addition, it appears that the temporary folder under the agent folder in the All Users/Digipede/Agent folder is not the one being used to run the application on the Agents in the 'standard', non-SDK debug situations.

The part in the API docs that seems to describe what I am expecting to happen that does not happen is this statement found under DigipedeClient.AutoIncludeDebugFiles Property:

'For each DLL and EXE in the JobTemplate, the Digipede Framework will check to see if there are matching PDB files in the directories with them. Any matching PDB files will be added to the JobTemplate and sent to the compute resources.'

So I want to know:

1. is there different behavior happening when the 'normal' 'Agent runs the application' scenario occurs vs. when the SDK debug scenario occurs? How can I manage the apparent difference of where the code assets are placed, how they get there and when they run. In particular how can i assure that all the necessary assets get to the proper location on the Agent in each of these two scenarios?

I'm prepared to understand that the following may be parts of this first question:

2. The Filedef's collection is built during Job object configuration, including the digipede added entries and the 'my applicaiton' added entries. But the AutoIncludeDebugFiles setting is attached to the Digipede Client object that performs the submit. This implies a separate type of functionality for the FileDef's collection and the AutoIncludeDebugFiles setting, as well as a separate time frame for the operations. How should I distinguish the behavior of these two features?

3. In general, I'm having problems managing the contents of the FileDef's collection. I frequently have errors where errors are raised stating that the key already exists in the collection. This typically turns out to be that a key is empty or that the path portion (which is the same every time) is set but the rest of the key is not provided. Although these are programmatic errors, the source is that I do not understand how to coordinate my entries with those that are 'automatically' added and, for example, why is the remote path of the automatically added entries pointed at the temp asp.net folder on the server? I'm puzzled about how the agent would resolve this address.

4. Is it reasonable to assume that the correct functioning of the agent is actually a result only of the fact that I am using the RunDirectory setting to point to a local folder on the Digipede server that is filled by an 'out-of-band' process (the web service installer)? That is, should I assume that the filedef's collection entries (as I am using them) have nothing to do with the normal activity of the Agent, but have everything to do with fact that the pdb's and other files not mentioned in the assembly meta-data do not arrive in the SDK debugger's temporary file?

5. Finally, just for a sanity check: is the temporary folder under the All Users/Application Data/Digipede/Agent folder the folder where the Agent normally runs the code? or is this created only for the situation where the SDK debugger is operating?

I have an immediate need for this understanding.

Thanks,

Kimball ]]> Digipede Network kimballjohnson http://support.digipede.net/community/showthread.php?t=256