this is a self answered question, it may be useful to others.
After installation, trigger.io won't start if the installation path includes special characters such as accented letters.
I found such problem after installing trigger.io on a windows XP in spanish machine (trigger.io installs in "C:\Documents and Settings\USER\Local Settings\Application Data" which in spanish is "C:\Documents and Settings\USER\Configuración local\Datos de programa", there is an accented ó in the path).
The log file toolkit.log reported some kind of unicode error.
Here is a quickfix, assuming your filesystem is NTFS:
0. Uninstall trigger.io
create a junction point for "C:\Documents and Settings\USER\Configuración local\Datos de programa" to a path without special characters, such as C:\USER\appdata. You could use Mark Russinovich's junction utility to do that.
open regedit and go to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Change the value for "Local AppData" to the new path and reinstall trigger.io.
By using a junction you don't have to copy the content from the previous dir to the new location, it's kind of a hardlink that works on directories.
IMPORTANT: this hack may have unintented consecuences on other applications, so use it at your own risk.
Related
I am working on this localization project for an app.
All of our English strings are in LocalizationResources.resx. Now we are trying to support for Japanese. We now include the Japanese version of resx i:e LocalizationResources.ja-JP.resx to the same location/solution project where english resx resides.
According to Microsoft there is no code change needed because .NET is smart enough to pick the correct resx file based on the current system locale.
When we run the app from Visual studio in Japanese locale, the app launches in Japanese. Thats good...
When we run the app by running an exe (generated by building the solution) in Japanese locale, the app launches in Japanese. Thats good as well...
BUT when we build solution to generate an MSI, then install it in Japanese locale, then launch the App it shows up in English!!! Clearly the visual studio and the exe know to read from Japanese resx but why doesnt the app(installed by MSI) run in Japanese???
I tried several combinations of settings for the resx file, such as "Build Action" = "Embedded resources", and "Copy to output directory" = Copy always/copy if new/do not copy.
I know for the fact that our packing tools do not differentiate or exclude any file from being part of MSI. So how to resolve this?
I'm trying to install Daggerfall onto my computer.
It asks me for the installation directory; the default is C:\dagger, but I want it to install to C:\Program Files (x86)\Dagger. Problem is it doesn't allow for spaces or pretty much any punctuation, so what I tried to do was replace spaces with underscores.
Sadly, that didn't work, because now I get the error message, "You have entered an invalid DOS path. Please correct this."
Is there a way to designate the installation directory as C:\Program Files (x86) here? If so, how do I do it?
NOTE: This may seem at first like it would be better posted in Arqade, but I feel it's more appropriate for this site since this question has more to do with DOS input than it does at all the game. I'm asking about the directory itself and the way to type it correctly, so it's not 100% game-specific.
DOS did not support long directory names. Usually, we would install games under C:\games or similar. You are limited to 8 characters (excluding the extension).
Windows knows this, and will present "short" path names for backward compatibility with FAT16.
Your directory will most likely be C:\PROGRA~1 or similar. An easy way to find out is to run cmd.exe and then go to the directory in question:
cd "c:\program files (x86)"
Now use the trick from this answer to get the short name:
for %I in (.) do echo %~sI
I'm realizing a custom setup for my outlook addin. I want the installer in Dutch language, but VS 2010 doesn't support this language.
Is there a solution to my issue?
The default procedure to make a dutch language msi setup is to use orca.exe on the msi file and translate the TEXT column of some tables. (you can also do this by extracting the msi database and by importing it back in the msi when the translation has been done).
But there is the other way: Creating the language support directly in the Setup project creator.
I'm using VS.NET 2003 (yeps still the old version) and when you create a setup project you have no dutch language support in the project localisation. I figured out how that thing works but I'm stuck in the language change of the msiloadr.bin and the webloadr.bin files (both dll files included in the distribution) (step 3 in the comment below). The unusual procedure to include directly the language support in the VS.Net Setup project :
1) get the local identifier and the code page for your language (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_238z.asp)
2) Go to the VS.NET/Common7/Tools/Deployment/VsdDialogs directory and copy 1033 (english) directory to 1043 directory (dutch). Translate all the files in that directory with orca.exe and update the 1033 language code to 1043
3) Go to the VS.NET/Common7/Tools/Deployment/MsiRedist directory and copy 1033 (english) directory to 1043 directory (dutch). Here we need to update the bin files (DLL) to set it up as a dutch language.
4) Update the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Deployment\DialogTemplates:)
Append ", Dutch" to the Languages key
Append ", 1043" to the Identifiers key
Append ", 1252" to the CodePages key
Once you have done that you'll be able to compile any Setup project in the dutch language and this can be done for all the missing languages. (If you solve the 3rd step)
Maybe you have some solution to solve for the unofficial sulution by tweaking VS.NET :-)
Copied from: http://social.technet.microsoft.com/Forums/windows/en-US/2d062f34-5615-47c8-aa7b-a69fbd68e983/how-to-make-a-installer-in-dutch-language
Please read this :-
Set up creation using selected language
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.
I'm using MikTeX 2.8 edition, and installed the hungarian language support and hyphenation files. Using the standard LaTeX command they work fine, but when I try to use pdfLaTeX, they don't get loaded and I get the
(C:\stuff\miktex\tex\generic\babel\magyar.ldf
(C:\stuff\miktex\tex\generic\babel\babel.def)
Package babel /b/c12/cWarning:/b/c0/c No hyphenation patterns were loaded for
(babel) the language `Magyar'
(babel) I will use the patterns loaded for \language=0 instead.
message. Using latex it works fine:
(C:\stuff\miktex\tex\latex\00miktex\bblopts.cfg)
(C:\stuff\miktex\tex\generic\babel\magyar.ldf
(C:\stuff\miktex\tex\generic\babel\babel.def)))
I tried updating the FNDB and the Formats, but to no avail.
I had the same problem in Windows 7. I installed MikTeX and configured the hyphenation languages under administrator account and when I started to use pdflatex under my own account, it turned out that it did not detect the languages that I had added in the MikTex Settings (Admin) application.
The solution was to run MikTex Settings under my own account (i.e. the non-Admin program in Start Menu) and click the button "Update Formats".
I have the same problem with MiKTeX 2.8, babel, pdflatex and language "portuguese".
Regular latex works fine.
Went back to MiKTeX 2.7 and the problem doesn't happen.
Removing MikTeX 2.8 and cleaning the registry by hand, then reinstalling it solved the problem. (simply removing and reinstalling didn't solve it)
First find out language.dat file under your installation. Then find there a string like %magyar bla-bla-bla, remove comment (% mark), or, if there is no such line in that file - add it. Bla-bla-bla stands for the exact name of file with hyphenation table, you should google of how does that called.
Then run "update formats" from the miktex options menu, BUT - do that for the Options, and NOT for Options (Admin) menu.
Good luck!