I need my 32-bit InstallShield installer to make a change to ApplicationHost.config (Part of IIS7). I want to set the value of overrideModeDefaults from "Deny" to "Allow" for the ipSecurity configSection.
This works fine in Windows 2008 32-bit, but not in Windows 2008 64-bit. The problem is that the installer only looks in systemWOW64 for the file, but it is actually in system32.
Is there a way for me to edit this file programmatically from my 32-bit installer? I'm okay with running a script or even doing it post-install with my 32-bit configuration tool.
I think I've found my own answer. Turns out you can use %windir%\sysnative to access the system32 directory in a 32-bit application.
Related
'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine. I am getting this in visual studio only after upgrading from 32bit office 2013 to 64bit office 16. I have already installed the 64bit database engine and my published project from IIS is working with the existing access database. I switched debug mode to x64 and remove the references to the old office and replaced them with the new office access. How can I get Visual Studio 2010 to recognize my access database created in access 2013?
Things I have tried:
Installing Microsoft Access Database Engine 2010 Redistributable 64bit version.
Updating the office references in the project.
Debugging in x64 mode
This is a little outside of my normal area of database application design;
it's unclear - you state 2016 Office 64 bit installed but then Access 2010 Redistributable/Runtime 64bit - - so do you have a full license of Access installed?
if you do have the full Access license - try something that is quick: create a brand new database and import that table. Then try the link to this new db.
I had that issue in the past.
install 2007 Office System Driver and restart visual studio.
I've dealt many time with this problem, the solution was ever install one of these:
AccessDatabaseEngine 2007.exe
AccessDatabaseEngine_2010.exe
AccessDatabaseEngine_2016.exe
AccessDatabaseEngine_X64_2010.exe
AccessDatabaseEngine_X64_2016.exe
Most of the time I've solved installing the 2007 one even using 2016 version.
To run 32-bit applications on IIS, you will get the same error. So, from the IIS 7, right-click on the applications' application pool and go to "advanced settings" and change "Enable 32-Bit Applications" to "TRUE".
Restart your website and it should work.
My task is simple: I need to test my ASP.NET web application in a 64-bit environment on my development machine. (At this point I don't even ask about running it through a debugger. All I need is to run it in a 64-bit process.)
So I created a stock C# Web Application in Visual Studio 2010 and adjusted its properties as such:
I then did Ctrl+F5 (or run without debugging) and IE loaded up and hangs up like so:
What am I doing wrong here?
PS. Running it on Windows 7 Ultimate (64-bit).
We had the same problem and when the team jumped to Visual Studio 2012, this registry key was really useful to us :
you can add a registry key to force visual studio to use the 64 bits version of iisexpress.exe ; unfortunately for you, it is a VS2012-only solution.
reg add HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\WebProjects
/v Use64BitIISExpress /t REG_DWORD /d 1
Then restart Visual Studio and tick [X] Use IIS Express in your settings.
(see also the source).
UPDATE: For reference, in Visual 2013, this option can be found in the interface : Options/Projects and Solutions/Web Projects/Use the 64 bit version of IIS Express for web sites and projects
In IIS make sure the Application Pool, Advance Settings, Enable 32-Bit Applications = false
If this setting is true then the worker process will run as 32bit WOW64 process.
Chris
No settings required in project or solution level. I am developing WebApp on VS2010 on 32 bit and 64-bit machines simultaneously. Actually We are working on SVN and our few machines have Win7 32-bit and my few mates have Win7-64bit laptops. But there we haven't faced any such issue while compiling the app on two different machines and Even on the live server, it runs butter smooth. Hardly care about the bit and bytes.
To verify a test run. Publish your code and host in your local IIS or Cassini Webserver and access it over LAN.
Also if possible revert back solution and project settings to its original configuration settings. Generally, We do not need to change target until and unless it is strictly required. As, AFAIK, It compiles the assembly under "Any CPU" as target, which is eligible for all i.e. IA, X64 and X86..
Finally, if you are coming across any error, please do post it here. It will help you and us as well.
First of all how to do you know if your IIS process is running your website as 32-bit or 64-bit as of now?
Open Task manager to check the bitness of w3wp.exe. If your machine is 64-bit then IIS will run 64-bit by default. Your problem seems to be something else. If bitness is the issue then you won't even come this far. Check IIS logs (c:\inetpub\logs{website-ID}{date})... that might give you some pointers. If there is nothing in there, check event viewer. If nothing then check if the virtual directory is actually created in IIS Manager under Default Web Site.
Have you actually tested if IIS (sans ASPX) is functional? http:// localhost ? does that work? if that is working then I would recommend checking if your ASP.NET modules are properly installed within IIS.
Hope this Helps.
I have a 32-bit application that I'm packaging with InstallShield 2009 Premier. I would like to be able to install it on 32- and 64-bit machines, but the InstallShield installer doesn't seem to be able to automatically detect that it's being run on a 64-bit machine and consequently redirect the creation of registry keys to HKLM\Software\Wow6432Node... and the creation of files to C:\Program Files (x86)... Despite my best googling, I can't seem to find out how to configure the InstallShield project to account for this.
Any ideas?
Since you have a 32-bit application, you need to leave its installer the way it is.
Wow6432Node and Program Files (x86) were specifically designed for 32-bit applications. On a 64-bit machine Program Files and HKLM\Software are for 64-bit applications only.
A mixed 32/64-bit installer can be used only for an AnyCPU application.
I wrote an asp.net web app which uses SMO against SQL Server 2008 to be able to run some DB scripts. It references these assemblies (in the C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies folder):
Microsoft.SqlServer.ConnectionInfo
Microsoft.SqlServer.Management.Sdk.Sfc
Microsoft.SqlServer.Smo
The microsoft.sqlserver.batchparser.dll is not in this folder.
Locally (32 bits machine, IIS7) I have no issue.
When I publish the app to my hosting provider (discountasp.net, SQL Server 2008, IIS7, 32bits too), I get this error:
Could not load file or assembly
'Microsoft.SqlServer.BatchParser,
Version=10.0.0.0, Culture=neutral,
PublicKeyToken=89845dcd8080cc91' or
one of its dependencies. The system
cannot find the file specified.
I searched my local machine and I can't find this assembly. However it works well on this machine.
The "Microsoft SQL Server 2008 Setup Discovery Report" tool reports I have v10.1.2531.0 installed locally.
To get this dll, you will need to install the Microsoft SQL Server 2008 Management Objects (available from here). That particular dll gets installed into the GAC, which is why you probably cannot find it using a search.
As you are using a hosting provider, it would appear that they do not have this installed. Your choices are to get it installed by them (which is probably unlikely), or deploy the dll manually (which may be on dodgy licencing ground).
First you need to enable browsing of GAC folder:
1. go to Registry Editor (RUN > regedit)
2. go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
3. Right click Fusion > NEW > DWORD
4. Type DisableCacheViewer
5. Double click DisableCacheViewer
6. Set value to 1
then you can find it here
C:\Windows\assembly\GAC_32\Microsoft.SqlServer.BatchParser\10.0.0.0__89845dcd8080cc91
You need to have the SMO components installed on your hosting provider as well. You can download them here.
I had a similar issue, but with R2. For me it worked by installing Microsoft® SQL Server® 2008 R2 Shared Management Objects and dependant Microsoft® System CLR Types for SQL Server® 2008 R2.
Find them here http://www.microsoft.com/en-us/download/confirmation.aspx?id=16978
I resolve this only Just Right Click on Project navigate to Properties and Change Platform Target from 'Any' to 'x86'
You could install the SQL Client Connection feature from the SQL Server DVD as well. I installed that as well as the SDK components to resolve this issue while installing SolarWinds.
I had SMO x64 installed, but SMO x86 was required on build server.
<startup useLegacyV2RuntimeActivationPolicy="true"> in App.config
This happened to me today. Running as administrator did the trick for me, I'm not sure why.
It's not ideal for production, but might work just fin for development environments.
Install the 'Microsoft Visual C++ 2013 Redistributable (x86)' if it is not showing up in add/remove programs.
(Note: I thought about posting this to serverfault, but I figured more developers have banged their heads against these issues than admins)
I'm trying to set up a web page that uses both ASP Classic and ASP.NET 2.0 in the environment mentioned above. After applying many common fixes on the web and a few lucky guesses, the ASP.NET 2.0 pages are finally running fine (Minus COM+). The ASP Classic pages aren't running at all.
So I'm thinking the x64 environment is a the cause of most of my problems. Is there anyone here using old COM+ stuff with ASP Classic and ASP.NET in x64 and IIS7 with some words of wisdom?
You need to set the application pool to 32 bit mode ("Enable 32-bit Applications" in advanced properties). Set anonymous user permissions correctly. More IIS7 ASP material from learn.iis.net.
When working with x86 stuff in one of the fancy new x64 environments, look over your shoulder at every opportunity for configuration settings that need to be applied to both sides(x86/x64) of the operating system.
My problems were being caused by two groups of configuration settings that had to be set in both x64 and x86.
To enter the settings in the x86 side, here are some tips:
Copy any needed DLLs into the sysWOW64 folder.
Use a 32-bit Console to launch utilities such as the SQL Server Client Network Utility (cliconfg) and Registry Editor (regedt32). Using the 32-bit console will launch these utilities from the 32-bit system folder (%windir%\SysWoW64). I made a shortcut pointed to %windir%\SysWoW64\cmd.exe and launched it as an administrator.