Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. WCF and WF
  4. Crash accessing resources

Crash accessing resources

Scheduled Pinned Locked Moved WCF and WF
hardwaredebugginghelpquestionannouncement
3 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F Offline
    F Offline
    fjparisIII
    wrote on last edited by
    #1

    The following code worked for months, and in fact I still have the last backup of the source that works perfectly. But if I make the slightest change to that source code, or try a rebuild-all, the application crashes when it hits the GetResourceStream:

    Uri uri = new Uri("Resources/PhotoHelpDesk.exe", UriKind.Relative);
    StreamResourceInfo sri = null;
    try
    {
    sri = Application.GetResourceStream(uri);
    }
    catch (Exception ex)
    {
    string reason = ex.Message;
    }

    PhotoHelpDesk.exe is an Embedded Resource. reason is the following: "Cannot locate resource 'resources/photohelpdesk.exe'." Remember, this exact same code has been working for months! This started happening in VS2010 RC. It seemed completely irrational, and so I rebuilt the project from scratch and the first time I executed it, it worked! I guess that means I successfully got it to the point of my backup. But do a rebuilt-all from that point, and it crashes. I thought it might be a VS2010 bug, so I back-ported the code to VS2008, and exactly the same thing happens, so there's no point in working with VS2008 on this bug. The last build that works was a Debug build. So tried making a Release build and just switching from Debug to Release also makes it crash. Then switching back to debug from release makes it crash again! It seems as if just rebuilding the source, no matter what, causes it to crash. This code is near the beginning of the execution of the application (it is an installation wizard). If I just skip this code and proceed on, as soon as I get to other resource accessing code near the end of the wizard, it crashes in code like this:

    Uri uri = new Uri("Resources/" + resourceFile, UriKind.Relative);
    StreamResourceInfo sri = Application.GetResourceStream(uri);

    Essentially the same code as above only this time I'm dynamically creating the path to the resource. Does anyone have any ideas about what could be causing this? Does anyone have any questions to ask me for further information? How could it work for one build and then simply rebuilding cause it to fail?

    modified on Friday, April 9, 2010 11:14 PM

    F 1 Reply Last reply
    0
    • F fjparisIII

      The following code worked for months, and in fact I still have the last backup of the source that works perfectly. But if I make the slightest change to that source code, or try a rebuild-all, the application crashes when it hits the GetResourceStream:

      Uri uri = new Uri("Resources/PhotoHelpDesk.exe", UriKind.Relative);
      StreamResourceInfo sri = null;
      try
      {
      sri = Application.GetResourceStream(uri);
      }
      catch (Exception ex)
      {
      string reason = ex.Message;
      }

      PhotoHelpDesk.exe is an Embedded Resource. reason is the following: "Cannot locate resource 'resources/photohelpdesk.exe'." Remember, this exact same code has been working for months! This started happening in VS2010 RC. It seemed completely irrational, and so I rebuilt the project from scratch and the first time I executed it, it worked! I guess that means I successfully got it to the point of my backup. But do a rebuilt-all from that point, and it crashes. I thought it might be a VS2010 bug, so I back-ported the code to VS2008, and exactly the same thing happens, so there's no point in working with VS2008 on this bug. The last build that works was a Debug build. So tried making a Release build and just switching from Debug to Release also makes it crash. Then switching back to debug from release makes it crash again! It seems as if just rebuilding the source, no matter what, causes it to crash. This code is near the beginning of the execution of the application (it is an installation wizard). If I just skip this code and proceed on, as soon as I get to other resource accessing code near the end of the wizard, it crashes in code like this:

      Uri uri = new Uri("Resources/" + resourceFile, UriKind.Relative);
      StreamResourceInfo sri = Application.GetResourceStream(uri);

      Essentially the same code as above only this time I'm dynamically creating the path to the resource. Does anyone have any ideas about what could be causing this? Does anyone have any questions to ask me for further information? How could it work for one build and then simply rebuilding cause it to fail?

      modified on Friday, April 9, 2010 11:14 PM

      F Offline
      F Offline
      fjparisIII
      wrote on last edited by
      #2

      I may have solved this. I have to do some more experimenting. I tried a different technique for getting a Stream from an embedded resource. Since this new technique seems to work, I strongly suspect that I wasn't using GetResourceStream properly, although it sure seems weird that it worked just fine for months. This new technique doesn't work with a Uri. Instead it works with a rather strange syntax for specifying the resource path, where the components are separated by periods rather than slashes. The first component has to be the namespace of your assembly, followed by a period-separated string of folder names. Suppose the assembly namespace is Install and your resource files are in folder, Resources. Then the following function returns a Stream for the resource file:

      public static Stream GetStreamFromEmbeddedResource(string fileName)
      {
      try
      {
      Assembly a = Assembly.GetEntryAssembly();
      Stream str = a.GetManifestResourceStream("Install.Resources." + fileName);
      Debug.Assert(str != null);
      return str;
      }
      catch (Exception e)
      {
      string reason = e.Message;
      return null;
      }
      }

      That's quick and dirty. I'll clean it up for my final code. In the meantime I have to do some other things before I give my final blessing to this technique. I inadvertently used .NET 4.0 when I built my application and my beta customers are not ready for that so I have to revert to .NET 3.5. I'll make another post and report my results.

      F 1 Reply Last reply
      0
      • F fjparisIII

        I may have solved this. I have to do some more experimenting. I tried a different technique for getting a Stream from an embedded resource. Since this new technique seems to work, I strongly suspect that I wasn't using GetResourceStream properly, although it sure seems weird that it worked just fine for months. This new technique doesn't work with a Uri. Instead it works with a rather strange syntax for specifying the resource path, where the components are separated by periods rather than slashes. The first component has to be the namespace of your assembly, followed by a period-separated string of folder names. Suppose the assembly namespace is Install and your resource files are in folder, Resources. Then the following function returns a Stream for the resource file:

        public static Stream GetStreamFromEmbeddedResource(string fileName)
        {
        try
        {
        Assembly a = Assembly.GetEntryAssembly();
        Stream str = a.GetManifestResourceStream("Install.Resources." + fileName);
        Debug.Assert(str != null);
        return str;
        }
        catch (Exception e)
        {
        string reason = e.Message;
        return null;
        }
        }

        That's quick and dirty. I'll clean it up for my final code. In the meantime I have to do some other things before I give my final blessing to this technique. I inadvertently used .NET 4.0 when I built my application and my beta customers are not ready for that so I have to revert to .NET 3.5. I'll make another post and report my results.

        F Offline
        F Offline
        fjparisIII
        wrote on last edited by
        #3

        I went back to my original source (with an enormous back history of source control check-ins that it will be nice to keep) under VS2010, .NET 3.5, Release build, and it works! Whew!

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups