I have to maintain a number of minor legacy apps and most of them have no or minimal documentation. There are a couple of these which were written either in VB5 or 6, but I can't tell which. There doesn't seem to be big difference in the appearance of the source code, and I can load either one using VB6, and even run them in the IDE, but I have the feeling that the older of the two is VB5. Is there a way to tell by code inspection which one a project was created in? Or some other way.
The .VBP file for a VB6 project will contain a line like this:
Retained=0
VB5 project files do not contain this line. You can load VB6 project files in VB5, but you get a warning about the invalid "Retained" key.
It's in the project file.
Also, if you have had both installed, when you OPEN the project file from Explorer, it should start the "VB Selector" tool that will figure out which version to open for that project.
Related
I wish I could provide a better description, but this is hard to describe succinctly.
Let me start with some background. This is a C++ solution using Visual Studio 2019 Community Edition. It has 12 projects of different types (DLLs, static libraries, and executable tests) and 4 build configurations ((Release, Debug)x(Win32, x64)). Keeping all the properties the same across projects and configurations has been a massive pain, so I decided to try using property sheets so that I could have the properties shared across projects. Given the structure of my solution, the property sheets are themselves somewhat complicated, but it's an improvement over what I had.
However about halfway through this migration I noticed some odd behavior. When I inspect the properties for one of my projects (a static library), the properties page is almost totally empty. Not only the properties I have changed with my sheets are missing, but even the default properties that you would expect.
However when I build this project, I can tell that most of the custom properties are in fact set correctly despite being missing, so it would seem like a UI bug, except some properties are not set correctly, for example the build log is not written to the correct location despite being set in the property sheet. This makes me worried that other more important properties may not be set correctly as well, but it's hard to know which properties are getting set and which are not.
I have another static library project that is set up in the same way with the same property sheets, and it behaves normally. It shows the expected properties in the project properties, and the build log is even in the correct location.
It gets even stranger. When I run the build from the command line using msbuild or devenv, the build log is written to the correct location. This suggests that building from the command line is working correctly, and that building from Visual Studio is not the same as building from the command line.
I ran msbuild -pp to see the expanded project file, and it looks correct. I diffed this project file with another static library from my solution that is working normally, and the diff is as expected, only the project names, paths, and source files are different. I did this diff on the expanded projects files too and they were the same except the expected differences.
I have closed and reopened Visual Studio countless times. I have also unloaded and reloaded the project. I have even tried deleting the .vs folder. None of these had any affect.
Here is a link to my code.
Screenshots demonstrating what I mean.
Is there any way to fix this? Have I done something wrong? I would like all of the properties from my property sheets to show up in the project properties, and I especially need all of them to apply when building the project.
Moving the <ItemGroup>s containing the source files below the <ImportGroup>s in my project file (.vcxproj) fixed the problem. I cannot explain why this works, or why this was ever a problem in the first place, but it fixed it.
I am a Visual Studio noob. My background is more Unix-related and mostly used to building things via scons or make. I don't even have much Eclipse experience.
Anyway, I am frustrated how it seems very difficult to move files between projects in VS. (I am running Visual Studio 2013). For example, suppose I have a ProjectXRel (release) and I want a ProjectXDev (development). I want them both to be runnable, and the dev version might have just a few editing changes that differ it from the rel version.
The intuitive thought is to just copy the files from ProjectXRel to create ProjectXDev, but VS seems to fight me on that (it wants to rename all the namespaces to the title of the project).
Also, some of the files, like .cs files derived from .dbml via OR designer, seem uncopyable, and rely on one replicating the process of using the utility to having valid files. I'm used to a project being defined by its files, but that's not really the case in VS. Instead it seems defined by process steps used to create and organize the files.
Also, do serious developers just use command line calls and powershell? That's seems harder, but at least you know what the %#$$# is going on.....
So, the basic question is, how does one replicate an existing project to produce a similar one for development purposes? (I know source control such as git could help with that, but that's not an option for this situation.)
Thanks!
You should be using the same project for both Development and Release.
The things that are different between Development and Release should be stored in a config file (web.config or app.config, depending on what type of project).
You should then be using Configuration Transformations to transform that .config file into Development or Release.
In Visual Studio, right click on the project and click Add New Item, select "Application Configuration File".
In this file you can put connection strings or key/value pair settings in the AppSettings element (MSDN Link).
Once you have your basic settings defined, you can then right click on the config file and click Add Transformation. This will add transformations for each of the Project Configurations you have. (by default Debug and Release).
It will look like this:
Now you can build deployment packages.
Or install Slowchetah and then when you press F5 to debug it will run the selected project configuration with the configuration transformation applied.
I have this old VB6 project that is composed of a few DLLs, OCXs, and GUIs.
There is a GUI component that includes this in it's VBP file:
Type=Exe
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#C:\Windows\SysWOW64\stdole2.tlb#OLE Automation
Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll
Object={3050F1C5-98B5-11CF-BB82-00AA00BDCE0B}#4.0#0; mshtml.tlb
Reference=*\G{64E54C86-D847-48F7-9AE5-D6C9B8E6A3A2}#3.0#0#..\..\bin\Crypt.dll#Crypt
Reference=*\G{B3E7F95C-B6D9-458E-B4D4-5272759B139A}#4.0#0#..\..\bin\SpeechMike.dll#SpeechMike_DLL
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX
Object={AB4F6C60-4898-11D2-9692-204C4F4F5020}#29.0#0; Ccrpsld.ocx
Object={48E59290-9880-11CF-9754-00AA00C00908}#1.0#0; msinet.ocx
Object={9C526969-AA6E-4D61-BAFA-117FD20C2B38}#3.0#0; SpeechMike.ocx
The Reference settings are a pain since they always change from one machine to the other. I mean, the GUID '9C526969-AA6E-4D61-BAFA-117FD20C2B38', for the last one as an example, will be something on my system, but something else on somebody else's machine.
For now, to make it work, I erase References to Crypt.dll and SpeechMike.dll. Also Object SpeechMike.ocx. Otherwise, Visual studio looks for something that does not exists. Then in "project > references" I check both Crypt and SpeechMike and the Reference goes back to the VBP with the proper GUID and version. Finally, in 'project > components' I add the OCX and I'm good to go.
Am I wrong about that? How can I share the project with some else without going through hoops and loops to start the project?
I'm using MS Visual Basic 6 (part of VS 6 enterprise).
This sounds like "failure to maintain binary compatibility." Normally you only do this to yourself, but of course it can be a bigger headache if multiple people are compiling your libraries from the source Project files.
When you create ActiveX EXEs, DLLs and OCXs you need to create a "base" version where type and class ID values (GUIDs) get assigned. The documentation even suggests that you do this leaving the procedures empty: just a comment line or something so the IDE does not remove the empty declarations.
You don't have to use an "empty" base reference library, it can be one with full code in it.
Once you have compiled this baseline library, you'd exit and save your Project. Then rename this "empty" library as something else and from there keep it along with your Project source files.
After this you re-open the Project and go into Project Properties and on the Component tab change the Compatibility setting to Binary Compatibility and in the box there enter the full path and name of your compiled baseline library. Save the Project. Now you can add code and compile the "real" library to be used by other programs.
When you distribute these libraries (DLLs, OCXs) to somebody else in source code form so that they can compile them you must provide this renamed compiled baseline library along with the source code files, VBP file, resource files, etc.
From there your GUIDs will be stable until you make a change to something that breaks binary compatibility (changing a method's argument list, etc.).
There is more detail on this in the online Help (MSDN Library). See:
Using Visual Basic|Component Tools Guide|Creating ActiveX Components|Debugging, Testing, and Deploying Components|Version Compatibility in ActiveX Components
I have a VB6 project, when I came to check in changes to the VB6 project file I noticed that the Visual Studio 6 IDE had automatically inserted the following line:
VersionCompatible32="1"
What does this mean?
As an aside: Is there a good resource to help me make sense of the VBP file?
The VersionCompatible32 value in the VBP file seems to be part of the binary compatibility settings of an ActiveX project, maybe the typelib it needs to be compatible with (there can be several in a library).
When my project is set to no, or just project compatibility, this value is removed.
Note that the compatibility setting itself is stored in the CompatibleMode value.
First of all, I don't think it is a good idea to edit the VBP file manually. As far as I know, VersionCompatible32 is a hint about the VB(A) version that was used to save this file, probably for newer versions to recognize changes in the file format.
I'm trying to build a small VS 2005 solution I've just checked out of source control, and I'm getting this easy to understand error:
...\AssemblyInfo.cs' could not be
opened ('The system cannot find the
file specified. ') (The file is fairly
obviously missing)
Because this file's automatically generated, I've never paid it much heed before, and in VS 2003 (which I still work with day to day - pity me) it never seems to matter if it's missing.
So 2 questions:
1. How can I get VS 2005 to regenerate the file.
2. Could anyone explain to me in a couple of sentences what the assembly info file is all about, why it's generated, why it's a good idea to have an automatically generated file critical to my solution building etc etc.
Thanks - Andrew.
Edit: OK, I've googling some more, and it's probably significant that this is in an Nunit Test Project.
Update: Deleting the reference in solution explorer an Alex suggested did the trick, and the project now builds, but I'm not entirely happy with that as a solution. If the file is so unimportant, why is it generated in the first place? And if the file does perform a vital task, what am I missing out on by just deleting it?
Also, is it even possible to get it back? Either by getting VS to regenerate it, or by manually hacking one up (possibly using another as a template)?
This file contains assembly-wide settings like assembly version, name, etc. It is automatically generated when you change those settings using properties pages of the project. You should have this file in the project with sort of transparent icon (I think it is in resource folder or something like this by default). Locate it in the project tree and delete it. Visual studio will stop looking for it during build.
PS: assuming the path starts with .. and not ... then this file should be located one folder up from the project in the source control. So you can try looking there.