Need help troubleshooting; Code won't run for some users

[Anonymous]

I have written a handful of apps for AutoCAD which are used by a department of about 25 engineers here in Oregon. 

Recently, I was asked to deploy some of the apps to a department in Santa Clara, CA.  Easy; I just took our apps and changed the paths to their network share/server.  I have access to their network and can test the apps.  They work perfectly well for me.  However, when I deploy the dll files and they attempt to run the apps they get errors of various sorts, generally either unhandled access violations or the runtime simply hangs up and stops for no apparent reason.

The fact that the apps run on my machine accessing their network indicates no typos in the paths and everything is written correctly.  But something is preventing the apps from their using them on their own network. 

As an example, I've attached a .txt file containing code from one of the apps; this app opens a couple of dwg files and specific layouts, creates a dsd file for publishing and publishes a multi-page dwf  of those layout tabs in a specified location.  When they run the app in Santa Clara, everything works up until the end where it goes to publish the dwf using the publisher.dsd file. 

Is there anything I'm doing wrong in the code which would make it work for users at one site but not work for users at a distant site?  Any configuration of their ACAD that I'm overlooking (they have plenty of memory and sufficiently fast processers)?  What should I be looking for in troubleshooting? 

Thank you for any responses.

Erik

[JamieVJohnson2 · Accepted solution]

My experience with that issue points to user permissions on the local machines, and network being different than expected.  Windows may be throwing the errors, blocking the file writes, or waiting for rights elevation without displaying a message to the user.

[norman.yuan]

I hope (and believe) all the hard-coded file paths for the DWF publishing in your code are only for test/discussion, and the real code would take an input for the file paths (as opposed to hard-coded).

So, to verify if the code works or not in terms of publishing, you can easily replace the network paths with local drive paths that the user has no problem to write file to. If it works, it would be almost sure the network paths are the problem (user does not have permission to write file there).

To better handle this, before network path is passed into your code for actual work, you can always test if the current user can write file to that folder or not, something like:

private Function HaveWriteAccess(string networkPath)

{

  try

  {

    string testFile=@"networkpath\PublishTest.txt";

    If (!File.Exists(testFile))

    {

      using (var stream = System.IO.File.Open(testFile, System.IO.FileMode.Create))

      {

        stream.Close();

      }

    }

    System.IO.File.Delete(testFile);

    return true;

  }

  catch(System.IO.IOException)

  {

     return false;

  }

}

Hopefully, you have UI at the beginning of the app where user can choose a publish location. Or, you have app settings to set the publish location for all users (but may still want to be flexible for user to choose different location. Then, the code would always test access permission, before actual publishing starts, if the path is not local.

[Anonymous]

I re-pathed the destination to the user's C:\Temp directory and the DWFs published with no problem.  The issue was apparently a write-access issue between the user and their server which they'll have to sort out.  I didn't anticipate that because the server which was pathed in the code is their own server and they have all of the standard administrative permissions there and shouldn't have any access issues writing to it.  But at least I know it's not a code issue.  Thanks for the suggestion.

Erik

[Anonymous]

I did determine that the issue was the user's own permissions and access on their server.  However, I'd like to address your other points about hard-coding paths into code.  Your response seems to imply that doing that is bad practice, but I'd like to point out an instance (mine) where that is useful and, indeed seems to be a useful practice.  If you know of an automated workflow which is better for my needs, I'd love to hear about it as I'm never one to assert that my way is the best way, or even a good way.  So, please offer feedback if you have any.

The drawings I'm publishing are composites of xrefs.  The individual xrefs are sections of a manufacturing facility which are themselves working drawings.  The individual drawings are updated daily based on factory conditions.  At the end of the day I publish a dwf of the composite as a snapshot of factory conditions at that point in time.  The composite drawing is always the same filename in the same location, so the path is hard-coded as there is no browser selection desired.  Likewise, the dwf is always published to a consistent destination which stakeholders have access to in order to review the published snapshot.  Hence, the hard-coding of the destination path.  

I have about 60 such composites to publish as DWF files each day, so I've automated the process to run after I've left for the day; the code goes to a composite drawing, publishes a dwf, then goes to the next one.   If I had to manually browse to each composite and manually select a destination for each dwf I'd be here all night.  With the application I've written, I start it up and it churns away for a few hours in the middle of the night and in the morning I have nice, fresh, up-to-date DWFs for our users to play with.  

I hope that makes sense.  If you see a better way to go about this, as I said, I'd love to know about it.

Thanks,

Erik

[JamieVJohnson2]

So in response to your response to Norman regarding the hard-coding of file paths.  It does make sense to have a static value, but also being able to change that value without re-compiling your code comes in handy during situations where the IT changes the server out, or renames a share, you would appreciate that ability.  For me it came when we changed the server 3 times in a single year.  Several years later, I really appreciated that feature.  What I did was to create a data table (in sql) that the code loaded when getting the common path root (just the starting path, the rest was code constructed from user data with expected patterns), but you could just as easily create a txt file that stored the paths that all your code referenced when loading.  Not hugely vital, but definitely handy.

[Anonymous]

Thank you for that suggestion.

Yes, I'm familiar with that technique.  In addition to publishing dwfs of factory conditions, my overnight automated tasks include extracting data from around 1500 drawings.  The extraction paths are read from txt files which are easily changed as needs dictate.  So I could apply that same process to the dwf publishing application as well for cases you describe.  Even though our servers are very stable (nothing has changed for years), having that flexibility may someday turn out to be just the ticket.  

Thanks,

Erik