Let's say you update your project to a new OCX reference. As a result the GUID and other details of that OCX will change in the project's VBP file. So far so good.
However VB6 also writes the same information to FRM files (and maybe others, like user controls). But these files are NOT updated until they themselves are specifically / manually saved. This can lead to confusion when it appears that references are inconsistent.
There are other sorts of automatic changes VB6 makes to files also, but seemingly only when you touch the file manually.
It would be very handy if there were a way to force VB6 to resave every file and make sure it is totally up to date - say, on the build machine. Then you'd know for certain what the most up to date clean copy was as a point of comparison.
I don't know of a command-line option that can do this... but maybe someone knows a trick.
There's an add-on created by Martin Liss in this thread:
SaveAll.DLL
I didn't try it myself but it could do what you are looking for. I assume you tried Save Project?
Related
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'm currently trying to make a download/install file for a CD, and I've never done this or written any type of coding before so I'm somewhat at a loss. When we last created an installer package (I wasn't employed yet) we used InstalShield, but that was decades ago, and we can't afford the 500$+ price to get it again.
Currently I'm trying to work off the old download package we have. There is the Windows Installer Package (made by InstalShield) called CD Cat v6.msi, and then another file called CDcatv6.exe (which launches a window for the customer to browse options) and then a file called Data.cab which has all the files for the entire catalog in it.
I was thinking perhaps I can just replace a lot of those files with the current information. Replace the CDcatv6.exe file with my v7.exe file (but change the name so its CDcatv6.exe) and then replace all the files in the Data.cab file with the current ones. But that's turning out to be a huge issue.
I did a bit of searching to learn what a .cab file was, and downloaded the Cab File Maker 2.0 (after quite a bit of searching!). I'm having a difficult time using it though, as it wants all the files that I put in it to make the .cab to be in .ddf format. I have no idea what that is, much less how to make it. I tried using 'save as' to do it, but since all the files I need are PDF's there's no option for it and I cant export the files to it either.
I tried looking at other ways that people made Cab files, but I don't know many of the file types or programs their talking about. I'm not a programmer by any means, but I have to learn quick I guess, so any information on how to do this will help greatly. Is it even possible to replace all the files seamlessly and have it work properly? Or is there an easier way to create a fill that the customer can click on and have it download to their desktop?
I don't think simple editing of Data.cab will work. There is installer logic stored in other InstallShield files. It could work if and only if the file set is the same, I mean no files changed its names, no new files added, no new registry entries required etc.
To create a CAB file, use cabarc.exe from Microsoft Windows SDK.
Creating a brand new installer may be a better option. Look at this tools for creating installers:
Advanced Installer
NSIS
WiX toolset (with tutorial)
You best solution is to use dark.exe (part of the WiX toolset).
This will enable to you decompile the MSI and CAB files, edit the installer source as XML and then recompile this into a new executable. Unfortunately this route is not for the faint of heart and what you save on price will cost you in time.
I'm curious how your company created an MSI decades ago, but Sasha is right about time and money trade-offs. However if you're working with Visual Studio, you might try the InstallShield Limited Edition for Visual Studio. It may have enough capabilities to suit your needs.
Thanks for pointing to CABARC, that looks exactly what i was looking for, due to information on:
https://learn.microsoft.com/en-us/previous-versions/bb417343(v=msdn.10)?redirectedfrom=MSDN#top
That make me look how to download it, but i found this post:
Where can I get the cabarc utility?
Where it explains CABARC may be obsolete and there is another utility called MAKECAB that cames with Windows 11, i had try it at command line and it is there.
Thanks a lot.
This is not a work-stopper in any way, but I thought I should ask anyway because it is a little annoying. Let's say I create a new project and start putting source files in a directory other than the default that shows up the first time. Afterwords, whenever I open the project, I have to navigate to the source directory once during that session. Like I said, not a big deal (but if solvable, then it's icing on the cake). Quite a few times I absentmindedly put the source file in the default directory and end up committing that file to the SVN and if I am lucky, going through all the files, removing them, then adding them again.
So my question is, is there any way to specify the default source directory on a per project basis?
I have run into the same nuisance. I like to put the public interface header files for a library in a separate directory, but end up with file directory typos because I forget to navigate to the correct directory when saving a new file. Unfortunately, Visual Studio does not offer a setting to change the default directory for new C++ source files.
I had the same problem when I started using build systems (CMake, Premake) which requires me to keep my project files separate from my source files, which hampered my workflow.
Although changing the default source directory seems impossible, if you aren't afraid to spend money, the workaround I found was to use the Visual Assist extension.
You can bind a shortcut of your choise to the Create File command which creates
a new file relative to the directory or your open file.
I'd also recommend to base one's workflow around the wonderful
Create from Usage command (which I think greatly boosts
productivity) which almost eliminates the need to manually create files.
The extension is great, albeit a bit costly. I would love to see Microsoft incorporate these features directly in the IDE eventually as they are found vanilla in a lot of other IDEs e.g. Eclipse, Intellij.
There might be some free extensions available that does the same thing, but I haven't found any.
Changing the Default Project Folder may help. This page demonstrates how to change the default for Visual Studio 2005, and it should be the same for later versions.
When I right-click my solution in the Solution Explorer and choose Properties I get a dialog where I can select the Startup Project.
I sometimes select Current selection (If it is an experimental solution with lots of projects I jump between), but most often it is a Single startup project selected, which would usually be the main WinForms applications or or Console application.
My problem is that whenever I do a treeclean with the tfpt command (Team Foundation Power Tools 2008) this setting is forgotten. So when I try to run my solution the next time, it has defaulted to some random project and I get an error stating that I cannot run a class library or something like that. Which is obvious of course. But where is this setting stored? Why is it forgotten when I do the treeclean? The solution file is still there, right? Isn't solution properties stored there?
Reference 1
Arian Kulp says:
I was struggling with trying to figure
out why a certain solution of mine
wasn’t starting right. It was in VB
with four projects. Upon initial open
it would set a certain project with a
DLL output as startup. If I set the
EXE as startup project, it was fine,
but when I distribute code I always
clean it by removing *.suo and *.user
files, and bin/obj folders. Upon
opening the “cleaned” version, it
would always revert to the DLL project
and fail to F5 nicely. The fix turned
out to be simple, though I’m curious
as to why I needed to do this at all.
In the solution file, there are a list
of pseudo-XML “Project” entries. It
turns out that whatever is the first
one ends up as the Startup Project,
unless it’s overridden in the suo
file. Argh. I just rearranged the
order in the file and it’s good.
I’m guessing that C# is the same way
but I didn’t test it. I hope that
this helps someone!
Reference 2
Setting the StartUp Project
Which project is the "startup" project only has any relevance for debugging, which means it's user metadata from the point of the solution and the projects. Regardless of which project is the "startup" project, the compiled code is the same.
Because of this, the information is stored as a user setting in the Solution User Options file (solution.suo) which accompanies the Solution file (solution.sln). The .suo file "Records all of the options that you might associate with your solution so that each time you open it, it includes customizations that you have made" according to MSDN.
The .suo file is a binary file. If you want to read or change it programatically, you have to use IVsPersistSolutionOpts.LoadUserOptions from the Microsoft.VisualStudio.Shell.Interop namespace.
I suspect that this setting is saved as part of the .suo file created whenever you edit a solution file. This file contains various user settings, such as breakpoints, watch data etc.
I cannot confirm this but that would be my guess.
Unfortunately its not XML its a binary file and not easily edited.
I just wrote a little command line utility for windows called slnStartupProject to solve this. It sets the Startup Project automatically like this:
slnStartupProject slnFilename projectName
I personally use it to set the project after generating the solution with cmake that always sets a dummy ALL_BUILD project as the first project in the solution.
The source is on github:
https://github.com/michaKFromParis/slnStartupProject
Forks and feedbacks are welcome.
Hope this helps!
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.