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. .NET (Core and Framework)
  4. VS.2005 C# app deployment help needed

VS.2005 C# app deployment help needed

Scheduled Pinned Locked Moved .NET (Core and Framework)
csharpc++visual-studiosysadminhelp
3 Posts 2 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.
  • B Offline
    B Offline
    BambooMoon
    wrote on last edited by
    #1

    I have tried to put my C# applications and DLLs developed with VS.2005, including some C# DLLs that wrap legacy C++ DLLs (via Managed C++), on a computer that has no development environment. I thought if that computer had .NET 2.0 (and I am using some .NET 2.0-only components), my applications would run. They do not. They run fine on my development machine, but when I run the exact same executables on the exact same USB drive on another machine, they either fail to load (FileNotFoundException, but of course it doesn't tell you what file was not found), or they load but fail to work (unable to create TCPListener socket). Since there is no difference in the bits or in the directory, that leaves the path, as far as I can think. But apart from the VS.2005 development directories, the only path differences are to windows or winnt's system32 directory. So what does one need on a Windows 2000 or XP machine, both of which have ALL service packs and updates and both of which have just had .NET 2.0 installed on them, to get programs to run properly? Any help would be greatly appreciated. I have NOT made a deployment project of any kind and don't see why I should have to. I have just move the bits, including all dependencies from one machine to another.

    D 1 Reply Last reply
    0
    • B BambooMoon

      I have tried to put my C# applications and DLLs developed with VS.2005, including some C# DLLs that wrap legacy C++ DLLs (via Managed C++), on a computer that has no development environment. I thought if that computer had .NET 2.0 (and I am using some .NET 2.0-only components), my applications would run. They do not. They run fine on my development machine, but when I run the exact same executables on the exact same USB drive on another machine, they either fail to load (FileNotFoundException, but of course it doesn't tell you what file was not found), or they load but fail to work (unable to create TCPListener socket). Since there is no difference in the bits or in the directory, that leaves the path, as far as I can think. But apart from the VS.2005 development directories, the only path differences are to windows or winnt's system32 directory. So what does one need on a Windows 2000 or XP machine, both of which have ALL service packs and updates and both of which have just had .NET 2.0 installed on them, to get programs to run properly? Any help would be greatly appreciated. I have NOT made a deployment project of any kind and don't see why I should have to. I have just move the bits, including all dependencies from one machine to another.

      D Offline
      D Offline
      Dave Kreskowiak
      wrote on last edited by
      #2

      BambooMoon wrote:

      I have NOT made a deployment project of any kind and don't see why I should have to.

      COM registration would be one requirement. If your C++ .DLL's are COM-based, your Managed code wrappers wont work for what's not registered. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

      B 1 Reply Last reply
      0
      • D Dave Kreskowiak

        BambooMoon wrote:

        I have NOT made a deployment project of any kind and don't see why I should have to.

        COM registration would be one requirement. If your C++ .DLL's are COM-based, your Managed code wrappers wont work for what's not registered. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

        B Offline
        B Offline
        BambooMoon
        wrote on last edited by
        #3

        Thanks for the good idea. Unfortunately, mine aren't COM based. But I've discovered that at least part of my problem is the C++ runtime used by the wrapped classes. I need to get vcredist_x86.exe from Microsoft and install it. That got things running completely on one of the four machines where they weren't working. The other 3 still don't work. But I've opened a support incident with Microsoft, so perhaps on Monday I'll know why.

        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