In my company, people used to work with Visual SourceSafe, but some years ago they decided to start working with GIT.
I started working here some months ago, and as such I've never set up a Visual SourceSafe environment.
While debugging dumps from older versions, this is giving problems: it seems that the dumps (taken using procdump) contain commands for retrieving source code, using Visual SourceSafe.
I've just installed Visual SourceSafe, and I was hoping that this would make it possible to get the older versions of the source code, but this is not the case. (For your information, even after having installed Visual SourceSafe, I don't see any SourceSafe information in Visual Studio's "Team Explorer - Connect" window)
(the original question contains quite some investigation information, which seems to be obsolete now that the answer of this question is known)
How things are related
[...] it seems that the dumps (taken using procdump) contain commands for retrieving source code, using Visual SourceSafe.
A crash dump does not contain commands. It contains version information about the EXE and the DLLs that were loaded. WinDbg and Visual Studio will then look for PDB files which match that version information. The PDB file then contains information about the source code.
To find PDBs, you need a symbol server and/or a local path with symbols.
SourceSafe
I've just installed Visual SourceSafe, and I was hoping that this would make it possible to get the older versions of the source code, but this is not the case.
Installing SourceSafe does not help. You'll need to connect to a repository using Visual SourceSafe Admin and grant yourself access rights.
Then, using Visual SourceSafe (not Admin), map a local folder ("Set working folder") and pull ("Get latest version"). You then have the source code locally and you can instruct your tools to use that path. For WinDbg, .srcpath and .lsrcpath should be correct.
You might need to get different versions by date if you really want to analyze with source code. To automate this process, you would need a source server, but you would know if you have one.
The age of the dumps
You say:
[...] some years ago they decided to start working with GIT.
So your source code should be in GIT, not in SourceSafe.
If your crash dump file is so old that it refers to SourceSafe, then consider it as obsolete and take a new dump. If nobody complains about crashes recently, I would no longer care (saying that as a former Test Manager).
Unbelievable: the issue is caused because the SourceSafe installation seems not to be complete:
In order to get it working, the following needs to be done:
Add the SourceSafe directory to the $PATH$ environment variable (C:\Program Files (x86)\Microsoft Visual SourceSafe)
Create the $SSDIR$ environment variable in order for SourceSafe to know where to look for the source code (should refer to the directory, containing the srcsafe.ini file).
Related
I am running Visual Studio 2012 (version 11.0.50727.1)
I have been trying to install https://jsonsource.codeplex.com/, a tool to allow JSON data to be imported using SSIS. To install this, once I have copied the dll's into the correct folder, I need to register them using gacutilexe. this is where my problem starts. I am supposed to run Gacutil.exe from the Visual Studio command line. This is supposed to be present in the Start Menu as VS2012 x86 Native Tools Command Prompt (it isn't), I am also supposed to be able to access it using vsvars32.bat (using the add external tools menu in Visual Studio, and supplying the location of vsvars32.bat as an argument). However, I cannot find vsvars32.bat anywhere within my C drive.
I have found several versions of GacUtil.exe in various subfolders of C:\program files(x86)\Microsoft SDKs\Windows, although the installation guide lead me to believe it should be in C:\Program Files\Microsoft SQL Server\120\DTS\PipelineComponents, i.e. where I copied the dll's for the tool I am installing. I'm not sure which of these (if any) I should be using once I get to the visual studio command prompt. Could do with advice here as well.
vsvars32 is meant to be somewhere within C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools, but it is definitely not present any where within the Visual Studio folder.. There are also folders for Visual Studio 9 and 10, but these do not contain vsvar32 anywhere within them either.
if anyone could help I would be very much indebted - My options as to how to deal with the JSON source files otherwise are extremely limited. (using Management Studio 2012 rather than 2016, so can't use OPENJSON. If anyone can suggest any alternatives, let me know. This includes just any option to get the entire JSON file file into a cell - I could probably build some kind of extensive string manipulation to script to split it all out once I've got them in there, although this seems like entirely the wrong way to go about things...)
The first time you install the 3rd party package in Nuget Package manager, it will automatically download the .dll to your user temp folder, once you close it, it will gone, but it will register for you. If you need to find where the exactly location is, simply double click that new added .dll in solution window, if you try to reinstall, but it does not allow you to do that, delete the package.config file, and try to reinstall that package. Once that is added again, do not forget to double click that .dll, to see where is reside, move to your own folder, register using gacutil -i command, and should be good.
Recently I have intalled VisualSVN and TortoiseSVN extensions in my Visual Studio 2015. I have successfully configured Repository and now it is working fine.
I have also configured svn:needs-lock property to my pages. Now, I need to know who is modifying or using the particular file and which is supposed to be committed.
The problem is that there may be multiple developers might be modifying multiple files and Now, I need a list of files which is exclusively checked out by developers. Just like a Pending Changes Explorer in Visual Studio for whole repository. So, where can I get a list of files which are being used same as Visual Source Safe Control?
If you need any information just ask me in comment I will add it.
Thanks!!
I want to version my visual studio 2010 debug builds. I'm going to use git. Right now all the project files are in 'project' and the output binaries are put by visual studio in the directory 'project\debug'. I've read a few questions on here that have ignore lists for Visual Studio but most of them have an ignore list that ignores the binary files, like the obj exe idb pdb ilk etc.
If I want to be able to debug my exe in the future what files do I need to keep? Is there any reason to keep the obj files? Does VS use them at all during debugging or tracing a crash? I thought I should keep at least the the pdb files and the exe. So that would be project.exe, project.pdb and vc100.pdb. But what about vc100.idb, project.ilk, project.res... etc. Is there an ignore list that will ignore everything that isn't needed to keep binary builds but keep everything that is?
I want to make sure if a user sends me a crash dump or reports a problem at some point in the future that I can go back to the version that was being used and be able to debug it. I had also hoped to make the binaries and debug files available in a remote repo so that anyone else could as well. Thanks!
Don't keep binaries in version control. Instead, build from source.
Since the binaries are built from source, and you have the source versioned already, just re-build the particular version as-needed. It will both keep your version control system lean and fast, as well as not cause merge headaches (which binaries are notorious for).
So, the answer is don't keep any binaries in version control.
If you feel you really must keep them, however, then just zip them up and store them like normal files using the tag of the build they came from.
I'm going to keep project.exe and project.pdb in the branch. The other files like *.obj, *.ilk, and *.sdf are not needed. Neither are the vc100.* files. I made my decision after speaking to a number of people in person and reviewing this:
File Types Created for Visual C++ Projects
and this:
Which Visual C++ file types should be committed to version control?
Although that SO question/answer does not answer my question it gave me a lot of good information. I also looked through my project.pdb for all the file references to confirm which files in my project that I needed to keep around. I used this command from the debugging tools for windows:
srcsrv\srctool -r project.pdb
I have got some old sources written in Visual Basic. There are *.bas, *.cls, *.frm and *.vbp files. As I understand, vbp is a project file. But I cannot open it with my Visual Studio 2008.
What version of VS should I install to open *.vbp file? Google says it is Visual Studio 6, but I am not sure and I cannot find Visual Studio 6 for downloading. Is there any publicly available free edition of Visual Studio 6 with Visual Basic?
Thanks.
vbp is indeed a VB 5/6 Project File.
VS6/VB5/VB6 are not free, so if you want to build the project you will need to spend $5 on ebay.
The VB5 Control Creation Edition (build COM components only) was the only free version MS released.
Older versions of VS.net included a way to import a VBP and upgrade it to VB.NET, but YMMV (significantly).
Edit; If you just want to look at the source/project structure all the files except .frx are plain ascii.
If you have an MSDN subscription, then VB6 is available as a free download. Otherwise try ebay like Alex suggests, but it usually costs significantly more than $5.
Microsoft recommends users get a 3rd party conversion program called ArtinSoft,
http://msdn.microsoft.com/en-us/ff793478
When opening the vbp file which is the project file, you will most likely have an import wizard show up, which after trying to import the project it will likely tell you there are a bunch of dependencies vb6 used to use which .net does not and will error out. You need to have vb5/6 installed or at least the dependency files installed in order to proceed with the import. You can view source code from the plain ascii text files of the .frM files.
To get a working copy of visual basic follow the following steps.
after much research I found out that the original Vb6 was distributed as a disk set, all CD's are just ISO files built up of folders and files. You can get a copy of an original ISO here. There is a google drive version floating around on the web of the ISO but personally that just seems really sketchy to me.
https://winworldpc.com/product/microsoft-visual-bas/60
in order to use the ISO you will need to unzip the ISO with WinRar, so download a copy of WinRar (its a widely used file archiver tool)
follow the install instructions here https://youtu.be/LXvd8IRw_ZI
"How to Install Visual Basic 6.0 on Windows 7/8/8.1/10" by "Matthew Marcelo"
** be sure to run the installation as administrator ** .\Micrsosoft Visual Basic 6.0\extracted\SETUP.EXE
after getting everything installed I realized I needed a copy of the MSDN library (version October 1999) which is the developer documentation for using VB6, that is found here https://winworldpc.com/product/msdn/october-1999
--
if you are like me and had to get VB6 working because of a very old legacy project and you had no clue what .OCX (controller) files were, and you got a bunch of error messages when you open the main project .VBP file, when you get ahold of the files and install them, installing them as admin usually does the trick by making a batch file, or running an administrator powershell/cmd window
regsvr32.exe \path\to\file.ocx
you need Visual Basic, not Visual Studio to open these files. or you can open it using a normal text editor like sublime text file separately. but if you want to open it like a project then you should use Microsoft Visual Basic 6.0 / 5.0 . There is a portable version too.
If you still want to open .vbp file using visual studio try to use VB tools for Visual Studio. I think it will help you.
A lot of people new to CI (Continuous Integration) install VS (Visual Studio) on their CI server "because it is required to compile the code". MSTest is a common reference brought up here.
Why should I not install VS (or generally speaking, any software not out-of-the-box) on my CI server?
(This question has not been asked before apparently, so I'm adding it for reference. If it already exists, sorry, I missed it, please merge. If no answer is provided to this question within some time I can add one myself)
Because you don't need to. A Visual Studio license is pretty expensive, so having one just lying around on a server where no one's using it is just a waste.There are a couple of arguments why you would still need to install a full blown Visual Studio instance on your Continuous Integration server - but here are their counter arguments:
Reason 1: I need it to compile.
Reality: No, you don't. You need MSBuild to compile, but that is available for free, in the Windows SDK. Note that there are several versions for different operative systems and .NET versions, so be careful to download the correct one.
Reason 2: I need it to make quick fixes on the server.
Reality: No, you don't. You shouldn't make quick fixes on the server - you should check out from your version control system, make the fix, build and run tests locally until it works, check in, and have the CI system do the rest for you. That's why you have a CI system.
Reason 3: Without Visual Studio, I can't run MSTest no my CI server.
Reality: Wrong. AFAIK, the MSTest runner is also part of the SDK (at least that's what it seems like on our CI server here - although I can't verify it since we don't have any tests at the moment...). However, a quick googling found this blog post which explains how to do it without the SDK as well. I haven't read through it in detail, so I can't promise that it works, or that it's legal. You have been warned.
Feel free to add more reasons in comments, and I'll counter them.
You might need to install Visual Studio anyway, out of practicality
I was going to try and refute the accepted answer, posted by #TomasLycken, in the comments, but found I needed more space to talk. Even though I technically agree with what #TomasLycken has asserted, here, I'll list some of the dependencies that I found difficult to install on my CI server - and leave it to you to decide how right the accepted answer is...
1 - 'mshtml' primary interop assembly
You can see the problem I was getting in my build output at this S.O. question I created and answered. Mind you, I spent several hours figuring out how get the desired PIA registered - and it was a result of running some .exe's on the server that came from my V.Studio installation - hmmmmmm
CONTEXT: I had a win forms project that used the Web Browser control.. and in the 'WebDocumentCompleted' event, I was casting the DomDocument to hshtml.IHTMLDocument2 .. and that's why I had a reference to Microsoft.mshtml in my project.
RESULT: Now #TomasLycken suggests I deal with this by fixing my code. At first, I wanted to bawk at this suggestion. My code is deployed and working! But, when I do a web search, I see that Microsoft doesn't really recommend using their mshtml PIA outside of the Visual Studio environment they developed it for.
The offending 10 lines of code was effectively doing a little screen-scraping of data on behalf of our users who do research on technical topics in several well-known web portals. But, when I tested this code, written in 2009, it appears that the DOM it once manipulated has now changed in 2016. I know shocking. Probably not my smartest bit of code. Probably time to retire this function - in other words, fix the code and recommit it.
#TomasLyken I think is right on this one.
2 - Win Forms Project post-build script
CONTEXT: So I had come across this cool post-build technique on S.O. that allows my app.config file in my WinForms project to undergo an XDT transform similar to the way my web projects' web.config files are transformed. Well, it just works OOTB, so-to-speak, if you copy from S.O. and into the .csproj or .vbproj source file. But, once you put all this onto a build server with no Visual Studio, the critical piece fails due to a dependency on:
$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
Now this is straightfoward enough to rectify.. I just copied over to the CI server my C:\Program Files (x86)\MSBuild\Microsoft directory. But, should I? Since I've kinda went off the reservation of what Visual Studio normally would support.. one could argue that #TomasLycken's accepted answer is still right on this point, too.
3 - Just getting all the .NET Frameworks and Multi-Targeting Packs in place
Points 1 and 2 above, were actually the last things I conquered in my attempt to get my first build job to run. And my first build job is for a solution stack that I've created and maintained over the past 8 years.. so it has weathered a few frameworks and would have some non-trivial texture to it. I knew it wouldn't be easy. In fact, I hoped by making a CI server that could build this .sln, that it would in fact be ready to build most any other solution we threw at it.
When I first received my clean "Windows 2012 R2" server, it simply had a lot of things missing.. and I'm wondering if I had installed Visual Studio first, if it would have rectified some of these things straight off?
Below is my synopsis of what I had to do - but it doesn't show the pain and suffering involved figuring it all out and the false starts. Maybe it'll help someone else, though.
> First, uninstalled 4.6.1 framework
-- (find Update for Microsoft Windows (KB3102467) and click Uninstall.)
-- also uninstalled anything from MS labeled with C++ redistributable (a later step will restore these)
> Then, install Windows 7 SDK (installs critical "reference assemblies" and a proper baseline 4.0 framework)
-- Then, install Multi-Targeting Pack for Framework 4.0.1 (netfx_401mtpack.exe)
-- Then, install Multi-Targeting Pack for Framework 4.0.3 (netfx_403mtpack.exe)
> Then, reinstalled 4.6.1 framework for 2012 R2 (KB3102467)
> Then, installed Microsoft .NET Framework 4.6.1 Developer Pack (DP461-DevPack-KB3105179-ENU.exe)
> Then, installed "Visual Studio 2015 Build Tools" (BuildTools_Full.exe)
> Downloaded a copy of nuget.exe and put it in the C:\Windows directory
4 - Getting rid of 'missing ruleset' warning MSB3884
From #kevinbosman's post on this GitHub issues thread
If you don't want to edit your Microsoft.CodeAnalysis.Targets file, please note that it is not enough to merely copy the folder C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets\ to the build server.
You also need to create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\Setup\EDev and add the string value StanDir = C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\
5 - Getting MSTest to run correctly
Need dlls copied into your build machine, some must register w/GAC more info here specifically:
Microsoft.VisualStudio.QualityTools.Resource.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Need a hive out of your dev machine's registry copied into build server
some warnings, if you want them to go away, according to this Microsoft visual studio help forum require a VS 2010 and feature pack 2 installation.