when I check if IIS6 metabase has been installed , in Window server 2008 x64 enterprise Edition.
use those code :
<Property Id="IIS_METABASE_COMPAT">
<RegistrySearch Id="CheckIISMetabase" Root="HKLM" Key="SOFTWARE\Microsoft\InetStp\Components" Name="ADSICompatibility" Type="raw" />
</Property>
<Condition Message="IIS 6 Metabase Compatibility feature must be installed">
Installed OR ((VersionNT < 600) OR IIS_METABASE_COMPAT)
</Condition>
whether I installed the IIS6 MetaBase or not, it always say "IIS 6 Metabase Compatibility feature must be installed",I have checked ,the registKey is exist.is Wix support this Windows Version? This one already reported by some one in the bug list. please check the below url for that bug.
http://sourceforge.net/tracker/index.php?func=detail&aid=3126222&group_id=105970&atid=642714
Please suggest some solution
You're probably looking into the wrong place in the system registry. If your package is x86 (see Package/#Platform attribute), and you're installing on a 64-bit (according to your question), the RegistrySearch will look 32-bit registry. See RegistrySearch/#Win64 attribute for more details.
Related
I installed CF 11 on Windows 10 Professional using IIS option as shown below. But when I go to IIS I don't see CFIDE folder there:
I thought the CF installation process would have created a CFIDE folder in IIS with its subfolder Administrator that points to the Administrator URL. But IIS did have any such folder. If I remember in Windows 7, installing CF 11 with IIS option automatically configure Administrator website in IIS - at least that what I recall I had done in Win7.
So I manually added a virtual directory in IIS and named it CFIDE with physical path as C:\ColdFusion11\cfusion\wwwroot\CFIDE that is a correct path on my system. But when I go to http://localhost/CFIDE/administrator/ or go to All Programs-->Adobe-->Administrator in Windows, I get the following error. Please help:
CF11 was initially not supported for windows 10. One of the recent update of CF11 started supporting Windows 10. You would need to install ColdFusion and Select Built in Web server while installing ColdFusion. Once its installed, apply the latest update from CF admin and re-configure the IIS connector using Web server Configuration tool.
OR
Apply the latest update manually:
http://coldfusionx.blogspot.in/2017/07/how-to-install-coldfusion-updates.html
And re-configure the IIS connector.
I have windows server 2012 and I have installed the IIS 8.5 but I could not see the URL rewrite module. How can I enable or install?
Download it from here:
http://www.iis.net/downloads/microsoft/url-rewrite
or if you already have Web Platform Installer on your machine you can install it from there.
Worth mentioning: you should download the x64 version!
From the main download page (https://www.iis.net/downloads/microsoft/url-rewrite) click "additional downloads" (under the main download button) and download the x64 version (because for some reason - the default download version is x86)
First, install the URL Rewrite from a download or from the Web Platform Installer. Second, restart IIS. And, finally, close IIS and open again. The last step worked for me.
Thought I'd give a full answer combining some of the possible intricacies required for completeness.
Check if you have 32-bit or 64-bit IIS installed:
Go to IIS Manager → Application Pools, choose the appropriate app pool then Advanced Settings.
Check the setting "Enable 32-bit Applications". If that's true, that means the worker process is forced to run in 32-bit. If the
setting is false, then the app pool is running in 64-bit mode.
You can also open up Task Manager and check w3wp.exe. If it's showing as w3wp*32.exe then it's 32-bit.
Download the appropriate version here: https://www.iis.net/downloads/microsoft/url-rewrite#additionalDownloads.
Install it.
Close and reopen IIS Manager to ensure the URL Rewrite module appears.
How can I check whether with ASP.NET 4 is registered to run in IIS 7.5?
There must be some way to determine this for sure, other than running
aspnet_regiis -i
from within the framework's folder.
I don't need to check this programmatically, just via IIS Manager or the commend line. I have an .NET page that is returing a 500 error, which I have determined could be due to ASP.NET 4 not being registered with IIS.
However, I want to be certain before I make changes to the server configuration.
Try to run aspnet_regiis with parameter -lv, i.e.:
C:\Windows\Microsoft.NET\Framework\v4.0.30319>aspnet_regiis -lv
This will give you the following output:
Microsoft (R) ASP.NET RegIIS version 4.0.30319.34209
Administration utility to install and uninstall ASP.NET on the local machine.
Copyright (C) Microsoft Corporation. All rights reserved.
2.0.50727.0 C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll
4.0.30319.0 C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll
4.0.30319.0 C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll
In this example, you can see that v4.0.30319.0, 32 and 64 bit dll's, are installed.
To install the latest version, for example after applying a .NET Framework update, use
C:\Windows\Microsoft.NET\Framework\v4.0.30319>aspnet_regiis -iru
Note: On 64 bit IIS servers, you need to use "Framework64" instead of "Framework" in the paths above. Strangely, I found on some servers with 64 bit "Framework" in the path worked, on others I had to use "Framework64" - simply try it out. If the registration does not work, run it again with "Framework64" in the path, it does not harm. In one case, I had to change the path using cd C:\Windows\Microsoft.NET\Framework, then I typed aspnet_regiis -iru to make it finally work.
You mentioned that you need to check it programmatically: The command above can be used in a batch file, and via this article you can find the string "4.0.30319.0" in the output (provided you're using "aspnet_regiis -lv > outputfile.txt" to write the output into a text file).
appcmd list config /section:globalModules /text:[name='ManagedEngine'].image
My business partner and I are co-developing a web app that's deployed on Azure. My box is based on 64-bit Windows 7, but my partner is using 32-bit Windows 7.
From within the VS2010 IDE when I added a reference to 'ieframe.dll' from my System32 directory (64-bit on my box), the IDE actually brought over the SysWoW64 (32-bit) version of the DLL.
Both dev boxes work perfectly with the 32-bit WOW version of 'ieframe.dll', but when we deploy to Azure we're getting a EntryPointNotFoundException when making an Interop/DllImport call into 'ieframe.dll'. So it seems like Azure wants to have the 64-bit version.
How can we deploy the 64-bit version to Azure but keep using the 32-bit version on our dev boxes?
EDIT: Obviously, we can do this manually by copying 64-bit 'ieframe.dll' somewhere and then manually place it in the 'bin' directory, but is there a better best-practice way to do this in Azure?
EDIT #2: For this scenario, we ended up changing the node for Azure from osFamily="1" to osFamily="2". Doing this installs Windows Server 2008 R2 which includes IE8 (rather than IE7 in Windows Server 2008 SP1). No need to mess with 32 versus 64 bit versions or manually copy DLLs up to the server.
If you are always deploying to Azure from a 64-bit machine, you can alter the project file to copy the correct DLL to the bin folder at build time based on the processor type of the machine performing the build. This works great for us because we deploy to Azure from a 64-bit build server. If this sounds like a good solution, follow these steps:
1 - Create an external lib folder that contains two sub folders named 32 and 64.
2 - Place the 32-bit version of the DLL in the 32 folder and the 64-bit version in the 64 folder.
3 - Open the offending project file in a text editor.
4 - Add the following node to the project file just after the ItemGroup that conatins the "reference include" items. This will copy the correct DLL based on system supplied environment variables:
<ItemGroup>
<DllToCopy Condition=" '$(PROCESSOR_ARCHITECTURE)' == 'x86' And '$(PROCESSOR_ARCHITEW6432)' == '' " Include="..\ext-lib\32\mydll.dll" />
<DllToCopy Condition=" '$(PROCESSOR_ARCHITECTURE)' == 'AMD64' Or '$(PROCESSOR_ARCHITEW6432)' == 'AMD64' " Include="..\ext-lib\64\mydll.dll" />
</ItemGroup>
5 - Finally, alter the project's BeforeBuild target like so:
<Target Name="BeforeBuild">
<Copy SourceFiles="#(DllToCopy)" DestinationFolder="$(OutputPath)" />
</Target>
Another option would be to copy the correct DLL to the bin folder based on a build configuration (less ideal). For example, if you had a build configuration named Production you'd follow the steps above, except step 4 would contain this:
<ItemGroup>
<DllToCopy Condition=" '$(Configuration)' != 'Production' " Include="..\ext-lib\32\mydll.dll" />
<DllToCopy Condition=" '$(Configuration)' == 'Production' Include="..\ext-lib\64\mydll.dll" />
</ItemGroup>
Yet another (and even less ideal) option would be to copy the 64-bit version of the DLL to the bin folder using an Azure startup task.
Hope this helps.
I need to test my website and on IIS, but I dont have my original Windows XP CD to install Windows components. Is there another way to install it or can someone suggest alternative methods for my purpose.
With Microsoft Web Platform Installer 3.0