I´ve tweaked the VC++ settings so that all of my actual code will go to one place, while compiler generated binaries will go to another. This ncb file is the exception though. It is a quite large IDE generated binary file (Intellisense database). I can´t seem to be able to move it anywhere other than the solution folder. I´ve reasearched on google and found a few references saying that this is impossible. Does anyone have a workaround?
Visual Studio doesn't allow you to move that file. This article on CodeProject shows how one person worked around this problem, by creating a "poor man's" version of symbolic links. This involves hooking Windows' CreateFile function. This approach seems like overkill to me; I think I would just learn to live with this limitation if possible.
Related
I'm working on a really old program for my employer that requires a manifest file. Unfortunately the project was developed in .Net 2.0 on VS 2005 (Academic Edition) and migrating/updating to a newer... whatever would be time consuming and the really not worth it.
I've found ways to add a manifest file to a .exe manually (which is kind of a headache and I would prefer to avoid that route if that is at all possible for me to automatically include a manifest file into the application? I've found a few things on it but the options they reference seem to be missing from the Academic Edition.
I've seen this direction but there doesn't seem to be a manifest tool node (or I'm doing it wrong, could be either one). I found some images the closest I could get was this:
And it's missing the Manifest node that was referenced.
Is this possible to do with Academic Edition, or am I just hosed into having to do it the Open .exe in VS/add as a resource method? If I have to do it that way, that's fine but if there's a better way then I would prefer the better way.
I'm new to multithreading and so, I wanted to start learning Boost threading. However, before I even start, I'd like to know how to get all the files working with Visual C++ 2010. As a beginner, it can be very frustrating having to deal with not just code related problems, but with a faulty installation.
Tried to find it online, but couldn't come up with any good resource.
Thanks in advance.
I had done that this week for first time too. I wanted to link it statically and apparently the installer just copy the dlls (I have to confirm this). Surely there is a better way to do it, but what worked for me was download the whole set and run the bat file that generates the lib files.
After that is just a matter of setting up the additional include and lib directories on the project.
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.
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.