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. Database & SysAdmin
  3. System Admin
  4. Source Safe troubles

Source Safe troubles

Scheduled Pinned Locked Moved System Admin
helpquestiondiscussionannouncement
2 Posts 2 Posters 1 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.
  • J Offline
    J Offline
    Jack Vanderhorst
    wrote on last edited by
    #1

    We have a shared project that is used in many solutions we have under MS Visual Source Safe 2005. This project has a reference to a third party component that we all have installed on our machines, located in the directory C:\Program Files\Some Third Party Component\Something.DLL Now, since we all have the shared project and the referenced DLL located in the same places on each of our machines, life is good. Now along comes the 64 bit world. A new development machine running a 64 bit operating system doesn't have a C:\Program Files\ folder containing the necessary 32 bit components, it has a C:\Program files (x86)\ folder. So either the 32 bit machines can check in the reference that works for them, or the 64 bit machine can check in the reference that works for it. Either way, someone is unable compile the latest version. This is also an issue for things located in C:\Windows\System32 and C:\Windows\SysWow64 One solution we have currently is to manually create and populate the (x86) folders and SysWow64 folders on 32 bit machines, which is working, I guess, but... gak. Has anyone else run into this fun yet? How did you deal with it? Is there a best practice here?

    V 1 Reply Last reply
    0
    • J Jack Vanderhorst

      We have a shared project that is used in many solutions we have under MS Visual Source Safe 2005. This project has a reference to a third party component that we all have installed on our machines, located in the directory C:\Program Files\Some Third Party Component\Something.DLL Now, since we all have the shared project and the referenced DLL located in the same places on each of our machines, life is good. Now along comes the 64 bit world. A new development machine running a 64 bit operating system doesn't have a C:\Program Files\ folder containing the necessary 32 bit components, it has a C:\Program files (x86)\ folder. So either the 32 bit machines can check in the reference that works for them, or the 64 bit machine can check in the reference that works for it. Either way, someone is unable compile the latest version. This is also an issue for things located in C:\Windows\System32 and C:\Windows\SysWow64 One solution we have currently is to manually create and populate the (x86) folders and SysWow64 folders on 32 bit machines, which is working, I guess, but... gak. Has anyone else run into this fun yet? How did you deal with it? Is there a best practice here?

      V Offline
      V Offline
      Vimalsoft Pty Ltd
      wrote on last edited by
      #2

      hi Jack Well i never came across the problem, just that it had my boss very angry when i wanted a file and he checkeditout somewhere in his system. am using vs2005/2008 and sql 2005 and i had no problems lately , i think i had a lot of problems with sourcesafe that i can master it and its bugs. The SS pluggin in VS sometimes it gets buggy. just make a backup of your work as a zip file so that your work will not be lost.

      Vuyiswa Maseko, Few companies that installed computers to reduce the employment of clerks have realized their expectations.... They now need more and more expensive clerks even though they call them "Developers" or "Programmers." C#/VB.NET/ASP.NET/SQL7/2000/2005/2008 http://www.vuyiswamaseko.somee.com http://www.vuyiswamaseko.tiyaneProperties.co.za vuyiswa@its.co.za http://www.itsabacus.co.za/itsabacus/

      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