I have to figure out what needs to be done to make a very old/shelved/unfinished C# asp.net code base into a working application if it's even possible.
I was pointed to the source where there's just a few things in the root, the important one seems to be this data folder.
It contains a whole bunch of folders mostly titled a, b, c, etc. And those contain files called something like baaaaaa or baaaaaaa.b. I can open some of these up in notepad and see plane old C# source code but it's basically meaningless in this organization.
I've never used SourceSafe, but from googling I guess this is how SourceSafe stored files and their changes or something?
If I have what I've described but no traditional solutions or source is it possible to get the original organized solution with properly name classes and such? Can I even use this? If so, how?
You are looking at a SourceSafe library. You need to:
Get VSS (Visual Source Safe, v6.0d is still available) on your client.
Point it to that root directory as a VSS library.
Then you should see the projects tree and be able to extract everything.
Related
I'm learning Visual Studio 2015 Community. I'm a seasoned programmer, but new to VS, and the file representation is confusing me. I've created a solution, and added an existing project. VS is showing me all project files (In my case a C++ project, so .c, .cpp, and .h files) on one tree level in Solution Explorer.
In contrast, if I open said project in something like Sublime Text, VS Code, notepad++, or the like, I see the proper directory structure as it sits on the disk drive; as one would see it in File Explorer/Finder or ls/dir in a terminal.
I have done my homework before I posted, and in the following thread, #Andrey states:
I am afraid there is no such concept in MSVS like "directory
structure". Moreover, MSVS doesn't really need it because it uses flat
projects and hierarchies are based on project level, not on the
file/directory level.
As there is no such thing - you can't have it neither automatically
nor manually. MSVS has solution folders which is quite different thing
and there isn't much sense in expressing real folders as solution
folders.
Visual Studio as Code Browser : How to preserve the directory structure?
Is this true? There is much meaning in the arrangement of files, and the flat representation in VS makes a project harder to understand; file location in the directory structure are important. Is there a way to view the proper directory structure in VS?
In my situation, I'm working with Quickfix, which supports multiple versions (4.0, 4.1, 4.2, etc.). Each of these have different classes and files with the same name.
As you can see from the screen shots below, they are all neatly arranged in different folders on disk, but VS's representation of these files is immensely confusing:
I found the answer given by #Paul Easter in the thread below to very helpful in understanding this "quirk," which is really a "feature." A different concept of project structure is at work:
But as for the reason you do not want solution folders to behave like
"physical" folders is because your solution layout may not necessarily
use the same convention as your source control layout. Solution
folders allow you to customize the hierarchy of your projects so that
you can group projects and items together any way you like, and then
decide you don't like it and change it again without having to go
through the nightmare of moving source control items around and
irritating the rest of your team.
Visual Studio Solutions Folder as real Folders
Is this a good idea? I can see where some people would like it, as it allows them to arrange project files as they wish. At this point, I dislike it; I'm sure in part because it is new to me, but also for these two reasons:
1. In an organized project, the directory hierarchy is not arbitrary; the Principal Engineer arranges files in a certain way for good reasons.
2. It adds a layer of abstraction between the VS file representation and the operating system structure. I like direct access to the files that I'm working on; with the VS system, I feel oddly and eerily disconnected from the underlying files in VS. I must admit a fear that this layer has its anomalies, and will cause problems for me.
We recently switched to team foundation server 2010 for our source code management, everything works just fine, except for some legacy code written in FoxPRO 7 and 9, source code files are some sort of tables. For Forms, there are two kind of files, one ending in .scx and another in .sct, both can be explored using the fox studio but there is no way to open them in a text editor.
does anyone have any experience getting the fox code to work/merge... on TFS ?
I'm not aware of all of the ins and outs for source control and FoxPro, but if some of the source is binary, you can configure file extensions to disallow merges.
Right-click on the collection (root node) in the TeamExplorer window. Go to Team Project Collection Settings | File Types.
You should be able to add the extensions (like .sct), and specify that merging and multiple checkout is not allowed for those files.
The downside will be that only 1 person at a time can check those files out, but since the forms are FoxPro tables, I would imagine that's the same problem that you would have with any source control tool.
For merging you can set up a merge tool that is capable of merging those files. This must be done on every developer station (Tools->Source Control->VS Team Foundation Server->Configure User Tools).
It may be that VS uses a server-side merge tool to do auto-merges, I don't know if or where you can change that.
I've worked with VFP since it was FoxBase back in late 80's. Visual Foxpro used .dbf files (renamed extensions) for purposes of building forms (.scx/.sct) and visual class libraries (.vcx/.vct) and reports (.frx/.frt).
I've written some code to run through a given project and dump out a text version of all the code as if it was all text-based. All the controls are dumped in alpha order, embedded procedures, etc too. List all property settings in same place too.
Its not PERFECT, but I've used over the years in comparing source code versions when dealing with other developers who liked to change things and not notify me (or others) of such changes and finding later by other horrendous means.
If this is something you might be interested in, I can strip-down the code (some) and send it to you via an email, but would need an email address. The code is written in VFP as a .prg file, so nothing compiled that you would need to worry about any viruses or anything.
At least this way, you COULD get a text version associated with the binary pair's of files used within VFP.
I could use some advice.
I'm in the process of adopting subversion, and I'm trying to put some existing Visual Studio 2010 projects into a repository. I have the current version of AhnkSvn.
The projects I have are organised as;
VS2010_projects\Project_A
VS2010_projects\Project_B
VS2010_projects\Project_C
VS2010_projects\Common_code
Where Project_A, Project_B and Project_C may all refer to one or more files in "Common_Code"
In visual studio, these files will have been added using "add as link".
There is no actual project in "Common_code" just a collection of useful code files, which we're likely to re-use in different projects.
(If we have a module or class which is re-used in various projects, then we often keep a single master copy in 'common-code', and link to it.)
Visual Studio has no problem with this.
When I add any of the actual projects to subversion, all of their own files are added just fine, but the linked files are ignored.
(And as a consequence, if I then get a working copy of those files, then it's just the project files which get handled, I won't get a copy of the linked files.)
If I right click on any of the linked files, I the only subversion options I get are to refresh their status or to select the working folder.
I was wondering what the correct way to handle this situation was ?
Any advice would be much appreciated
Thanks !
Robert
if I understand your question correctly then I think SVN is acting in the desired way. A linked file is merely a reference to another file. That reference exists only in the .csproj file which is checked in. It would not make sense to have two copies of the same file in source control, and it could lead to versioning issues. The first time you checkout your repository doing a build on your projects should copy the files from Common_code to the places that they're linked.
As an aside we've had alot of random issues with .csproj linked files and SVN, and so try to avoid linked files where possible. A better way to re-use files across projects is obviously just to embed them in a library and then reference that library. This should work fine with the exception of certain files like Javascript/CSS.
Also you may want to check out SVN externals, a workmate mentioned this can be used to share common libraries between multiple projects, although as a disclaimer I haven't tried this myself and can't comment on the merits or drawbacks of the approach.
Thanks for the advice, I actually did something similar to your suggestion.
I didn't want to make a full blown library, but I did make up a dummy project, and put my shared files into that.
Then I added the dummy project to the repository.
AhnkSvn now seems to be satisfied that the linked files are under subversion control, and seems to handle them just fine.
(I haven't added any reference to the dummy project to my existing projects - they just use the linked files as before - but now AhnkSvn shows me their status, and allows me to get the latest version, and commit changes.)
I can see the case for having a proper library - but that would have meant modifying a large body of existing projects. This approach lets me get up and running with Subversion without requiring those changes first.
In most .NET project I can use folder to organise the code files. In C++, I can't, but filters end up playing the same role. However, in F# with Visual Studio 2010, I can't. Every code file is shown directly in the project dir. Why is this feature not available?
And what is the optimal strategy for organizing a project with a lot of files?
Actually, you can add folders to F# projects but it's not supported directly through Visual Studio (you have to edit the project file yourself): http://fsprojectextender.codeplex.com/ (edit: old link was broken, updated to F# Project Extender home page which has links to the original blog posts which were moved) (which I found in this answer).
I do this myself, but it is cumbersome and you end up avoiding it until keeping sanity really demands it. I think the feature simply slipped, or perhaps there wasn't as much a culture for folder organization with the F# designers in the first place. You can see in the F# source code that they favor huge source files with no directories, with separate projects as an organization boundary.
I imagine the F# project template could be modified to support this, and it is certainly something I'd like to see happen. At the same time the linear compilation order F# enforces causes your code to be somewhat self-organized, and so folder grouping plays a less significant role.
Manually editing the .fsproj file as described in Stephen's answer is one option (and I used it when I wanted to organize one larger project).
However, you have to be a bit careful and I think you cannot add new files to the folders (creating a file by hand and then adding an existing file works). However, if you like to keep things organized (like I do), then it should work for you.
Additionally, there is also a tool called F# Project Extender that should make things a bit easier for you . I have not tried it yet, but it looks like it supports adding folders (and perhaps other useful things). See for example this blog post by the project author.
I've got a relatively simple project that is under source control (svn), and I wanted to create an installer. I know that I could (should) use WiX, but as I'm new to creating installers I thought it'd be easier to just use the built-in Visual Studio (2010) Setup and Deployment Wizard.
Unfortunately, it seems that files including external (non-project maintained) documentation, configuration files, and "Content" files are added with absolute paths. This, of course, is suboptimal. I searched the web, but found only the same question, without an answer. Another stackoverflow user seems to have asked a similar question, but the only answer, which suggests ClickOnce, seems off-base (I'd like to have an MSI that I distribute not a web-based installation).
Does anyone know how (or whether) this can be fixed?
With VS2005, sometimes the paths stored in the vdproj file were absolutes, and sometimes relatives. In my case, it seemed to be related to whether the files were accessed via the canonical path or not. Here's a concrete example:
Source is on C:\Views\builddir, open solution C:\Views\builddir\solution.sln and add files from C:\Views\builddir\.. and VS2005 would add relative paths into the vdproj file. However, if you map that builddir to a letter drive, for example, make a subst from C:\Views\builddir to s:, open the solution via S:\solution.sln, and then add files by navigating to S:\.., VS2005 would insert absolute paths into the vdproj files. Whether VS2005 displayed paths as absolutes or relatives had no relation to what it stored in the vdproj files.
So, it may well be that the problem comes down to what path you're using to open that solution.. opening \\server\shareddir\solution.sln might get different behavior than mapping \\server\shareddir to W: and opening w:\solution.sln.
You can always add the files, then use a text editor (e.g. notepad) to change the absolute paths in the vdproj file to relative ones. You'll be fine until you change that project again.
MS doesn't seem to really fix minor bugs like this so much as rewrite the code to introduce an entirely different set of bugs, so VS2010 might still act this way.
FYI, why would one want to map an absolute path to your builddir? It was a holdover from the bad old days when VS didn't do anything correct with relative paths.
As tzerb mentioned, the main source of confusion might be that paths show up as absolute under the property window inside VS, but when you look into the actual VDPROJ file you should see the paths show up as relative. However, as patbob mentioned, I believe the paths ARE stored as absolute when they come from a different letter drive.
It might be easier now but when you start bumping into the limitations of the tool it's going to get real hard. Let's not even talk about the bad practices it will encourage which could end up being real hard for the poor end user installing your product. You've got Visual Studio 2010 so InstallShield LE ( free ) would be a better choice.
Otherwise, to answer your question, it will only use absolute paths if it can't caculate a relative path. ( for example c:\foo\foo.vdproj consuming d:\foo.txt consuming c:\test\foo.txt should automatically be ....\test\foo.txt )
BTW, if you decide to check out WiX and want some "easy" check out my IsWiX project on CodePlex. I'm trying to bridge the feature gap between InstallShield and WiX.