I've installed the IIS Express 7.5 Beta 3 and tried it on multiple computers (Windows 7, Windows Server 2008 R2 and Windows XP) and on each one of them I get the following error when running
iisexpress /path:e:\onlineinvoices\
This is the error. It seems it can't find the applicationhost.config file. I've searched for this file myself too and found it in the AppServer folder of IISExpress installation folder.
Copied template config file 'C:\Program Files (x86)\IIS Express\AppServer\applicationhost.config' to 'C:\Users\marko\AppData\Local\Temp\iisexpress\applicationhost201115151422496.config'
Temp configuration file settings error.
The system cannot find the file specified.
The instructions here are pretty weird especially the ones that deal with configuration file. As a matter of fact it says that the applicationhost.config should exist in Users Documents folder but there's no trace of it there.
I had the same problem.
It started working after I ran IIS Express by double clicking on the C:\Program Files\IIS Express\iisexpress.exe.
After that it worked when I ran it from the command line.
Yes, launching iisexpress.exe one time should fix the problem. This is a bug that we will fix at the earliest opportunity. Using the /path option uses a temporary configuration file under the temp directory, which is setup to include the specified app. Without /path, iisexpress.exe uses the default applicationhost.config under documents and will create one if it doesn't exist.
Hope this helps.
Related
When I try to instantiate a VFP COM (OlePublic) DLL from my .NET web app running in IIS on Windows server 2016 I get:
Retrieving the COM class factory for component with CLSID {A55C4127-DDCB-4E5F-B69C-A7EAC83A83DC} failed due to the following error: 80004005 Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL)).
I was able to track it down (using Simon's comment) to it not being able to find vfp9r.dll:
Those files got installed w/ my InstallShield package under C:\Program Files (x86)\Common Files\Microsoft Shared\VFP:
vfp9r.dll
VFP9RENU.dll
vfp9t.dll
Why isn't "it" searching that dir? I got one server it is finding them under program files and another that isn't. How does that magic work?
update
if I install VFP 9, it will search that dir & successfully load it. So what is the VFP 9 install doing to my machine to tell "it" to search that dir not just the current dir & \SysWow64? 🤔
workaround
import these registry keys:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VisualFoxProRuntimeMT.9\Shell\Open\Command]
#="C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\VFP\\vfp9t.dll"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VisualFoxProRuntime.9\Shell\Open\Command]
#="C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\VFP\\vfp9r.dll"
(save the above 'script' as a .reg file and double click it to import it)
how I figured this out:
Hyper-V checkpoints so I could quickly go back and forth from a working to a non-working vm along w/ resetting after I did some test to find the minimal workaround
Search & export registry key w/ vfp9r.dll or vfp9t.dll
Compare exports via Notepad++ Compare Plus Plugin
The diff for vfp9t.dll was smaller so that was helpful. I grabbed the first key and that worked. Then I searched for the same-ish path for the vfp9r.dll export and grabbed that key.
I'm building a setup project by using InstallShield. The setup file will do the following tasks:
Install my application to the machine.
Look for a folder based on a common string (e.g: MySecondApp) because each machine might has different folder name:
Laptop1: C:\Program Files\WindowsApp\MySecondApp_1.2.3.4_asdfsjhewrnewj
Desktop2: C:\Program Files\WindowsApp\MySecondApp_1.2.3.5_asdfsjhewrnewj
In this folder, I have a config file named "myconfig.cfg". My setup file will modify this file by adding some new configurations.
Could you let me know how to do this by using InstalledShield?
Thank you very much
I've resolved this problem by writing a C# library and use it in InstallShield for searching and modifying my config file.
I am trying to publish a project to Windows Azure but get an error in the generated Microsoft.WindowsAzure.targets file related to length of paths and file names. How can I determine which is the problematic path or filename. The error relates to the "" tag in the generated file
Thanks
Martin
Already an older post - did you check this post?
Path too long error when building a windows azure service
This might reslove your issue.
Since this was still a problem for me years later and the above doesn't apply to Azure SDK v2.8, I was able to solve it by creating a symbolic link to my projects folder. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.
I've got a problem with changing the physical path of virtual directories on an IIS, while running on a TeamCity-Agent.
I'm changing the Path by using the <mkiisdir /> NAntContrib task. On the command prompt using nant it works just fine and changes the physical path too.
Under TeamCity the NAnt log output looks just fine, as if all went right. But when my web application starts, the physical path is still wrong.
So I started to use adsutil.vbs provided by IIS to change the physical path. On the command prompt it's working fine, but on TeamCity it does not change the path, although the build log shows that it was changed to the right directory.
I even stopped IIS before changing and started it back after changing the path, but it didn't help either.
I hope you can help me with this really annoying problem.
InnoSetup appears to be corrupting my executable when compiling the setup project.
Executing the source file works fine, but executing the file after installation produces Win32 error 1006 "The volume for a file has been externally altered".
I've tried disabling compression and setting various flags, to no avail.
Has anyone experienced this?
UPDATE
Okay there's been some twists to the situation:
At the moment, I can even manually copy a working file to the location it is installed to and get "The volume for a file...". To be clear: I uninstall the application, create the same folder and paste the files there and run.
UPDATE 2
Some more details for those that want it:
The InnoSetup script is compiled by FinalBuilder using output from msbuild, also executed by FinalBuilder, running on my machine with XP SP3. The executable is a C# .Net assembly compiled in configuration Release|AnyCPU. The file works when executed in the folder the Install Script takes it from. It produces the same behaviour on an XP Virtual Machine. The MD5 hashes of the source file and the installed file are the same.
Ok, I just received this same error. I have a config which my executable uses. I looked in my folder a million times - but finally notice the config file was zero length. I corrected the config and the error stopped occurring.
Check the simplest things first... good lucK!
ERROR_FILE_INVALID
1006 (0x3EE): The volume for a file has been externally altered so that the opened file is no longer valid.
I suspect you're having this issue after moving the files to a network share. It seems to me that what's happening is you have an open file-handle - possibly to a temporary file you are creating - and then some other process (perhaps running on a different host) is coming along and renaming or deleting that file or its' parent directory tree.
So my advice is:
Try installing to a local directory
Run after an anti-virus scan, in
safe-mode or on a different machine
to see if there isn't some
background nasty changing
volume/directory properties while
your program is running.
Make sure the program itself isn't doing anything weird with the volume or directory tree you're working with.
Never seen that before. I've got a few questions and suggestions:
- Are you signing the EXE during the compile of the setup? If so, try leaving that part out.
- WHat OS are you installing on or does it happen on all machines you've tried?
- Run the install with the /LOG="c:\install.log" option and post the log. It might show something happening during install.
- Run a byte compare or MD5 check on the source EXE and the installed EXE. Are they the same? Do they have the same version resource?