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.
Related
I'm in the process of building a program that has several external libraries and extensions outside of the main program files. My projects total size is 134.2 MB. I would like to make a portable version of it with Turbo Studio, but I face one glaring problem; After capturing the files and building the project I'm left with a 138.9MB executable. The program does run, but I don't want it to be so bloated.
I would like to bundle the bulk of the data as a separate .dat payload (or equivalent) but I can't seem to find any means of doing this with Turbo Studio. VMware ThinApp and Cameyo both do this automatically after the project exceeds a certain size, but it would appear that Turbo Studio doesn't.
Any help with is greatly appreciated.
There was a hack I had discovered some time ago that did exactly what you were asking.
It appears that the site that described it is not online anymore so read on.
Install your application while monitoring with TurboStudio.
If there are multiple entry points (e.g., a suite like office may have
shortcuts for excel, word etc) then make sure there are shortcuts for those entry points in the Start Menu. If there are not, then click Start, right click on All Programs, then Open All Users. Make sure you create in that folder shortcuts for all your desired entry points (e.g., one shortcut for word, one for excel etc.)
Capture and Diff with TurboStudio. Set your virtualization settings as desired.
Click Output File-->Browse, and select "All files(.)" in the Save as type list. Then enter a filename with the extension .dat
Build your app. You will now get a .dat file instead of an .exe
In the next step you must use ExeBuilder.exe. This file was originally hosted in csgotwisted.com. Do a google search for "2 utilities for spoon studio exebuilder" and it will most likely be the first result. Unfortunately, the link is dead now when I click it. So I uploaded the file to NitroFlare. You can find it here. Put it in the same folder as the .dat file and run it. It will create a shortcut with your executable. Sometimes it misses the icon, but it gives you the option to locate it manually.
I use TurboStudio often and I have found this way to be the most quick and reliable in allowing me to generate small executables and storing the virtual filesystem and registry in a .dat file. In addition, it has the advantage that it can get you multiple entry points and not only one, just like Thinapp does.
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.
Does it use modification timestamp or/and does it check whether the actual content has changed (e.g. by comparing the checksum)?
Edit: I need to know this since I use Git for source control and often change branches. It appears that sometimes even if I change the branch back and force (e.g. from develop to master and then back to develop), the VS rebuilds half of the sources files. I wonder why this happens and why does it happen sometimes and does not happen the other times.
Since Visual Studio is a closed-source project, I bet only developers would be able to give a definite answer on how exactly does it work. However, for my purposes it is enough to test some scenarios.
I have tested it with a small solution and a couple of files in it (one header and two source files). Test results bring to the following conclusion. Visual Studio looks for modification date and time. Even if the file content is the same - it compiles this file and also any other files that include it. If the modification date and time are the same - it won't recompile it even if the content is different. Visual Studio ignores creation and access dates and times.
I'm guessing it uses FileSystemWatcher on the project directories and linked files (if any), just because it's the right way to do this kind of thing.
Some googling finds for more about this class (or just look it up yourself):
http://www.techrepublic.com/article/use-the-net-filesystemwatcher-object-to-monitor-directory-changes-in-c/6165137
http://www.dotnetperls.com/filesystemwatcher
Of course when the source file is open, it's content by the time of editing, as wel as any user changes (even not saved) are loaded in the RAM, but it doesn't compare it to disk content (that'd be too slow), it listens to a system event when the system tells it the file changed.
Update:
Probably not that class itslf, but the Win32 version of it, you know most of the system related .NET functionality classes are just Win32 wrappers.
From this StackOverflow answer: How does FileSystemWatcher work on another computers directory?
I think it wraps this API (not sure): http://msdn.microsoft.com/en-us/library/aa365465.aspx
Update 2:
This is Microsoft's approach to monitor file changes:
http://msdn.microsoft.com/en-us/library/chzww271(v=vs.80).aspx
Update 3
This is an old answer, and it was mentioned above that it was a guess, as Visual Studio is closed source as mentioned in other answers. It's worth mentioning that the accepted answer suggests Visual Studio looks for file modification dates instead, which suggests it doesn't use the approach guessed in this very answer, and that it was wrong.
I hope the reader didn't mind the effort given to rationalize possibilities in this answer (causing reader discomfort or down votes). Keeping it for archival reason only.
I've written a basic LanguageService extension for Visual Studio 2008 for my studio's proprietary scripting language. It works perfectly fine, and I've implemented a basic symbol table to keep track of script definitions and calls allowing for goto definition functionality.
The problem I've run into is that I only know how to parse the current active view, and I'd like to scan the entire solution's contents so that the user can goto the definition of a script defined in a file they have yet to open and have parsed. I've figured out how to generate a list of all files in the solution, but now I need to create a new Microsoft.VisualStudio.Package.Source which requires a Microsoft.VisualStudio.TextManager.Interop.IVsTextLines and I have no idea how to create a new one based off of the file I have.
Maybe I'm going about the problem the wrong way and someone can point me towards a better way to cause a file to be parsed by the LanguageService.
Regards,
Colin
Poking around I found that the reason Visual Studio needs a new Source is that it's keeping an internal list of them, and they're like the view into the text file held by the editor.
I came to the conclusion that files that are closed do not need IVsTextLines or to be entered into the VS internal list of Source files because I'm not doing any operations directly on them, all I care about in this case is to build a table of symbols and their corresponding TextSpan. So instead I created a new API for my parser that just took in a string and built my AST instead of grabbing the text from a ParseRequest, and only worried about specific types of symbols I needed to record. I then pushed this into a BackgroundWorker.
So I guess I was going about the problem in the wrong way. Although it does seem weird I can't just trigger a file to be opened into the Source list.
Interestingly I asked this question to Microsoft on their support forums and they advised me I had to purchase some service and support plan for them to answer my question.
I have recently started using CAML.NET IntelliSense for SharePoint with Visual Studio 2008; which works great; however whenever I create a new project using STSDev 2008 (and thus generate feature.xml and WebParts.xml) the default schemas include the CAML.NET IntelliSense and the built-in (relatively incomplete) schemas:
caml.xsd
wss.xsd
coredefinitions.xsd
camlview.xsd
All found in web server extensions\12\TEMPLATE\XML. The existence of both of these schemas for the file causes a large number of warnings, notifying me that a specific schema entry is already declared in one of the above files. Disabling them for each file individually works great, however in a SharePoint solution whit 40 or 50 XML files this quickly becomes laborious.
Is it possible to disable these built-in Schemas, selecting "Do not use selected schemas" does not work for future XML files only the current one?
Well, if you really don't want them - you could remove the schemas from the xsd path (%VsInstallDir%\xml\Schemas) - and perhaps disable download (Options->TextEditor->Xml->Miscellaneous). My machine isn't in a suitable state to try it, but it should work in theory...