I'm pretty new to InstallShield - so bear with me.
I have created a Basic MSI installer that correctly installs our application and, until recently, every time I rebuilt it (with some new files for a new build of our application), it would replace the files with no issues.
However, I rebuilt it this morning with a new version, it flat out refuses to replace any files.
For example, out main exe now has a file version of 8.0.0.15, the one it is replacing is 8.0.0.13; the new modified and created date is 7/11/2013, the one it is replacing is 6/26/2013 for both - it still wont replace the old file with the new one (this is just 1 file in hundreds, but is the main exe and so it definitely gets changed with each release).
I have changed the properties of our own exe's and dll's to 'Always Overwrite' under 'Files and Folders' to no avail (I haven't touched the 3rd party dll's since they never changed).
I have changed the ResintallModeText to 'asum' to no avail - should I try 'asumv'?.
Before I have the application completely uninstall itself prior to reinstall, is there anything else I should be looking at to try and determine what may be preventing the installshield from replacing the files on the target machine?
I have no idea what could have changed to cause it to stop upgrading - we haven't had to make any changed to the installshield for some months since everything was running fine.
If you need logs or anything, let me know (though I can't get it to write out the installshield verbose log on install - but I can provide the Windows installer logs).
Thanks for your help!
Thanks to the comment from #anand which solved my problem as well. In my case, the executable was not updating even when I updated the product version (i.e. 1.0.001 to 1.0.002) and changing the package code for a new build.
The solution for me was to right-click on the executable in Files and Folders (in InstallShield) and select Properties. After checking "Always Overwrite" my executable now gets updated regardless of the product version or package code.
Related
I want to implement an autoupdater in my Python application. This is no problem with the source version; Python doesn't care at all that the script it's running is trying to overwrite itself.
Windows, however, does care if an EXE tries to overwrite itself. My question is, does my EXE even have to overwrite itself? Or is the EXE just an interpreter, and I only have to overwrite library.zip?
If it does, is there any alternative to starting an updater application and shutting down the main EXE?
The cx_Freeze exe is compiled along with cx_Freeze, so in most cases you can safely leave it alone and just update library.zip. However, you should make sure that you prepare your updates using the same version of cx_Freeze that you froze the application with originally, in case it expects specific things about the files around it.
Also, the exe gets stamped with a version number relating to your application (you can see it in the file properties). If you don't replace it, that version number won't change.
If you do need to replace the exe, I believe the trick is to copy it to a temporary folder and re-run from there, so that it can replace the original. You can also look into update frameworks like Esky, which aim to handle these kinds of details for you. I haven't used that, so I don't know how well it works.
After automatically upgrading the project file for a .Net 4.0 web application to work with Visual Studio 2012 everything worked ok at first however when compiling I got lots of errors like this:
Description : Source File '..\..\..\..\..\File Path' could not be found
File : CSC
And when trying to build using MSBuild (passing just the project full path, with no additional parameters) in the "Developer Command Prompt for VS2012" I got basically the same errors:
"CSC : error CS2001: Source File 'x' could not be found"
All errors refer to Linked Files (aspx,cs,etc) located in other web applications projects located at a different deep in our code Branch (that's why all the '....\' at the beginning of the paths)
To me it looks like a problem with the file Length, I had the same problem a while ago when building the projects on our CI server using MSBuild, I was able to manage it by manipulating the project files before building them using a custom script without the need to move the branch around or reduce the deep of the projects, I didn't have to move anything, the important thing at the time it was that developers using Visual Studio 2010 could compile everything without problems. I learned by this that compiling/Building with MSBuild was different that with DevEnv/VS, and for example MSBuild didn't support building Setup projects and DevEnv did.
Since this is happening now with VS 2012/DevEnv 2012 , plus that VS 2012 doesn't support setup projects anymore (like msbuild), plus VS/DevEnv have the same problem with the file length, it looks like VS 2012 its finally using msbuild under the hood or are more tightly integrated, however I didn't find any article to confirm this.
Changing the branch structure/changing the deep of the projects it’s not an option right now due to several reasons (large code base, high number of projects, risk, timing, effort, etc.).
Does someone have an alternative solution or a fix for this issue in Visual Studio 2012?
Regards,
P.D.: BTW I already checked this post MSBuild error with linked files but like I said before changing the paths its not an option right now.
Try getting the Build Logs,
http://msdn.microsoft.com/en-us/library/vstudio/ms171470.aspx
it seems that csc task could not find the source file. One cause it you import the wrong file.
so you have to edit the project file via normal Text Editor.
I found a solution to this issue, when you linked the file, you relative path is recognized by msbuild and go back from there it become your path in a long path however you can change it in the project definition doing right click/unload the project/ and change the path from ../../../ to $(SolutionDir)/../.. until find the file to link, note: it's extend the character from 255 to 300 character.
Check that you have the latest version of the linked files from the other projects. Visual Studio will NOT automatically get them if they belong to another project.
Check that the linked paths are indeed correct. You can monitor what files VS.NET and MSBUILD are trying to access with the help of the SysInternals ProcMon tool (filter on process names and filter out all successes)
If you suspect that the path length is the problem (this will also be visible in the ProcMon tool), you can try to shorten them by linking to the absolute path (C:\X\Y\Z) instead of a relative path (......\Z). The location of the linked files can then remain unchanged.
My 2 cents to this problem... In my case, I had a file created in one project (i.e. ConfigModel) and I had a link to this file in another project but when I renamed the file ConfigModel in the first project to LoginModel for example, it didn't rename the link in the second project causing this error to occur.
I know that i did this question a while ago but for what is worth, The approach that we finally went for was:
Locating the files that were reported as too long.
Reduce the full path length of those files, by reducing the length of the name and/or
the length of the container folder or reducing the folder nesting
level. Therefore reducing the full path length.
Update the links of the changed files (re-linking) on the dependant projects.
This solved the problem with Visual Studio 2012 on developers workstations and on our CI/Deploy servers that used MSbuild.
For my scenario this approach was less risky,and implied less effort than moving complete projects/solutions to reduce their folder nesting level or reducing the folder names, and have to update all the references of the dependant project/solutions.
Ok, I hit this and solved it today. I found it by following a msdn tutorial (https://msdn.microsoft.com/en-us/library/ms379563%28v=vs.80%29.aspx) and here's the command that broke for me:
csc /t:library /out:MyCodeLibrary.dll simpleType.cs
Giving me the message
error CS2001: Source file 't:librabry' could not be found
Which worked after changing the original command to the following:
csc /target:library /out:MyCodeLibrary.dll simpleType.cs
I'm not sure why the short version of the /target flag causes this error, but I've not found anywhere else online noting this cause specifically so I wanted to record it here.
This problem arose for me when I reverted to an earlier version of a git repository. Apparently I didn't add the project file to the repo so when it reverted it didn't revert the project file also. What I did to clear it up was to exclude the missing .cs file from the project by clicking on the missing file in the project Explorer. It was easy to find since it was marked with a warning triangle. Then rebuild the entire solution.
Verify whether the files mentioned in the error do not exist in the corresponding folder.
If their non-existence is intentional, edit the .csproj files and remove the reference for those files.
Build again.
I inherited this issue from a project somebody else was working on, in my case was a .cs file supposed to be generated by an Entity Framework .tt template, but for some reason it wasn't, so the compiler was going all CS2001 about that. I had to update the template and manually run it, everything worked after that.
For no reason that I can see, I can no longer run a TortoiseSVN Update on a development directory on my portable Windows XP Professional SP3 machine, getting the error:
Previous operation has not finished; run 'cleanup' if it was interrupted
Please execute the 'Cleanup' command.
If I try running cleanup, I get another error,
cannot process the following paths: cannot move $ROOT_DIR/.svn/tmp/tmp-... to $ROOT_DIR/path/where/thing/should/go: no such file or directory
I have verified that both files exist, and actually from CMD.EXE prompt I am able to issue a MOVE with those two filenames and have it work correctly. It's no use because next time SVN tries to repeat the operation itself after creating a different tmp file name, and while CMD succeeded, SVN fails.
UPDATE: the path lengths are in both cases well below PATH_MAX, target file system is NTFS, and permissions are OK. Maybe I'll now try with FileMon to see whatever TortoiseSVN is really up to.
I tried downgrading TortoiseSVN but to no avail. Other repositories work OK between the same machines.
TortoiseSVN 1.7.9, Build 23248 - 32 Bit , 2012/08/30 18:25:37
Subversion 1.7.6,
apr 1.4.6
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.1c 10 May 2012
zlib 1.2.7
Both server (OpenSuSE Linux 12.2) and client now run the latest version of SVN.
On Windows, I also cannot seem to get any more informative logs or information (I'm not very skilled with TortoiseSVN, I have always used the Linux command line version).
I might delete the local copy and run a checkout, but it's about 2 GB of data, and I'm on a slow connection, so it is really more of a "fly physically to server location and hook a copper Ethernet to the local network there" alternative. I'm reserving that as a sort of last ditch, nuclear option; I'd really rather understand what the problem is, for I fear it might happen again.
UPDATE
I've tried to delete remotely the subdirectory involved, committing the deletion on the server; deleting the subdirectory locally, and emptying the .svn/tmp subdirectory where I found sixteen tmp files, all copies of the one PNG causing problems.
I am still not able to perform any SVN subcommand, getting "Run cleanup!" error; on cleanup; I get a failed attempt to copy a tmpfile to the never-sufficiently-damned .PNG file, which no longer exists anywhere, into a directory that no longer exists anywhere.
I tried recreating the directory locally (but not the file!), no changes.
With FileMon, I traced the source PNG to 8e4c2389cf9d85c8b8ee54d49ea053c752a38187.svn-base in .svn/pristine subdirectory, tried removing it and got SVN complaining. I tried copying it to its intended destination (so that the file-as-it-should-be and the file-as-it-is are identical), no joy.
UPDATE
Well, this is weird. I decided to track everything that TortoiseSVN is doing using FileMon. I could see it checking the wc.db and search the item, checking for it in .svn/pristine (and finding it), copying it (unnecessarily if you ask me...) in .svn/tmp, and finally checking $DESTINATION_FILE (with correct case) using Windows Open() API. And getting PATH NOT FOUND. Yet the file is there, I can see it (and the name is less than 8.3 characters). And why PATH not found and not FILE not found?
Okay, it all boiled down to a directory that had been created remotely with a name ending with space. The file in itself was OK; the directory where it stood was not.
When updating, apparently, the directory got created but the name was shortened by Windows to exclude the final space.
To add to the difficulty of diagnosing, while TortoiseSVN did tell me what the problem was, it did so in the dialog box where the Arial font made the space in \path\to\your \file not clearly recognizable (it was, once I knew where to look, and compared that slash with the others. This one stood a little farther from the letter at its left).
Lesson learned: check really carefully the dialog file name, character by character (note to self: find a way of having it in Courier New if at all possible).
You may have two files in the repository that differ only in case. That's a problem on Windows. See this FAQ for details.
After few weeks of struggle i am able to create a medium native package debian package which works well in installation and removing of the package.
As http://www.quietsche-entchen.de/cgi-bin/wiki.cgi/-wiki/CreatingDebianPackages
Debian wiki
http://wiki.debian.org/HowToPackageForDebian http://www.debian.org/doc/manuals/maint-guide/ these are the quite good material for beginners,
I have basic problem, in updating the package all the files data.tar.gz are updated by default.
I want only few files to get updated in the data.tar.gz based on a key variable stored in all the files.
After the unpacking that is executing preinst script, all the files in data.tar.gz are already updated..
my idea was to take back up of the files intially before upgrading the package, and check key variable in files.. if the key variable is greater than the current variable replace it..
which means i am writing a simple backup script.. and executing in the postinst file..
i donot think this is good idea.. and more over limitations in dash script make it a very tough job..
What are you trying to accomplish here? During the reinstallation (or upgrading) of a Debian package, replacement of all of the non-conffiles with the latest version is exactly what's supposed to happen. If the file hasn't changed since the last installed version of the package then there's no harm in updating it anyway, and if is has changed, it's supposed to be updated.
If you have specific files which might be modified by the user and should be preserved across upgrades, make then conf files. The package system will prompt the user and ask them if they want to keep the package maintainer's version or the locally modified version.
(But if you're going to make every file a conf file, then you're probably doing something wrong.)
To make a file a conffile, list it in debian/conffiles. But if the file is going to be installed under /etc then you don't need to do this because dh_installdeb will do it for you.
EDIT following additional information in comment:
Suppose you have files test1.sh and test2.sh (among others) in your package. In the Debian world, they are either conffiles are intended to be modified by the end user, or they're not.
conffiles should be relatively few in number and as short as possible, to minimize the burden of having to reconcile changes made by the package maintainer with conflicting changes made by the end user.
If there are things mixed into the code that the end user is likely to want to tune, try to factor them out into a configuration file. If you put that file in /etc, you don't even have to manually designate it as a conffile.
If the end user needs to make a change to a non-conffile, they should use the dpkg-divert protocol to (1) move the original file aside, and (2) edit a copy. Diverted files are respected by package upgrades. The end user who uses dpkg-divert should be aware that things might break after upgrades as a result, because the package maintainer hasn't foreseen that these files would be modified by end users and the locally modified version might be incompatible with a newly upgraded version of a different file. dpkg-divert should be used carefully and sparingly.
I'm having trouble using macros in my .inf file that I'm using to create my cab, specifically when setting the InstallDir string. If I do something like this:
InstallDir=\<PathToProgramFiles>\MyAppName
then everything works fine. However, if I do this:
InstallDir=%CE1%\MyAppName
then I get the following error when trying to install the cab (double tapping it on my device): "MyAppName was not installed successfully. Please run Setup again."
This only seems to apply to the built-in macro strings. I can use %AppName% without any problems. Maybe there is some registry setting that isn't properly set that would normally resolve the %CE1% macro?
Any ideas about what is going on?
Edit: My device doesn't have a \Program Files directory. It seems the %CE1% macro always resolves to that path and if the InstallDir specified in the inf file doesn't exist (with the exception of the last directory portion then the install fails. Manually creating \Program Files fixed the issue. Since a lot of the devices I'm working with have different paths for their Program Files directory, is there a generic way to get the installer to default to the actual Program Files dir? I guess my only other option is to not specify a path and force the user to choose one?
First, in this link you can find the shortcuts and their meaning (the %C..%), goto appendix B. The Windows CE5 MSDN link.
You can add a Setup Dll to your CAB installaer that will check the directory structure and will create a folder in case it does not exist. You may find this SO question useful.
A warning: If you are targeting regular Windows CE devices, beware where you place the files as it can be to a RAM based file system and then the files will disappear after reboot.