I developed a Windows service which is running without any problem in Windows XP service pack 3. When I deployed this service in Windows Server 2008 it is not working. The service started without any problem.
I enabled the option Windows XP service pack 2 from the compatibility property of the .exe which deployed there.
But no more action after the starting the service.
What could be the problem?
One thing I would check it to see if any of your referenced assemblies are 32bit specific. We ran into a similar problem when using Microsoft SQL Server Reporting Services. The .dll we used to get a list of the web service interfaces, was 32bit/64bit specific, so we had to swap it out depending on which envionment we were running on.
Since the error could hide anywhere I would suggest to first discern what exactly is not working under Windows Server 2008.
Implement some logging functionality into your service (if you didn't do so already, I strongly recommend it) and let the result be printed into a log file. See what's working and when it stops to work. Hopefully this will give you a better understanding of what's going on under the hood.
Also, this way we can help you way better than now.
[EDIT]
Maybe these two can help you?
COM Class Factory Error
Running 32 bit app using 32 bit com on a 64 bit Windows machine
Related
I'm running Delphi XE on Windows 7 Pro 64 and IIS 7.5, developing an ISAPI application. IIS is configured correctly (including allowing 32-bit code to run in an ISAPI process). The ISAPI process runs properly.
In Delphi I'm trying to attach to the ISAPI process running on localHost to step through my ISAPI.dll code: Run->Attach to Process->InetInfo.exe.
I've done this a thousand times with Windows XP and IIS 5, but in this new environment I cannot attach to the ISAPI process. I get an error message in the IDE when attempting to attach:
Unable to create process - the request is not supported
This is costing me lots of time — I have to pump out debug strings for every line of code, run the app, and then look at my debug strings, etc.
Why can't I attach to the ISAPI process? Is this is an IIS 7.5 configuration issue? Perhaps related to 32/64-bit problems because IIS is native 64-bit and Delphi debugger is 32-bit?
Learn it here, http://blogs.msdn.com/b/david.wang/archive/2006/06/21/isapi-filter-and-the-iis6-process-model.aspx
To make it clear, in iis worker process isolation mode, w3wp.exe is the process that loads your isapi filters, so you should attach to it instead of inetinfo.exe.
You might wanna check this out:
http://www.embarcadero.com/products/delphi/64-bit
If IIS 64bit is using an ISAPI.DLL which is a 32-bit module, it must be using an 32bit loader process.
You could use ProcessExplorer to find which process is loading your ISAPI.DLL and attach Delphi to that process.
You can debug your 32 bit ISAPI dll on a x64 bit machine by setting the "Enable 32 bit application" to true in the advanced app pool settings in IIS 7.5.
In Delphi you specify the "C:\Windows\System32\inetsrv\w3wp.exe" as the host application with the params "-debug". Start the Delphi IDE as admin and off you go. If you need more control over how w3wp is started you figure out available options using the command C:\Windows\System32\inetsrv\w3wp.exe -?
Hope this helps!
You can debug your Delphi ISAPI Web Application under IIS 7.5 with the following tool
http://www.eggcentric.com/ISAPIDebug.htm. (You will need to set up the ISAPIFwd.ini file)
I am currently building an ASP MVC 2 site and I am looking at hooking ELMAH in for my error logging however I'm not sure how to handle the different build environments.
Both my development machine and current test server are 32-Bit and the production server is 64-bit. I can set the MVC site to deploy in x86 and x64 without any problems but is there any way I can get it to use the 32bit and 64bit ELMAH binaries on their respective servers without needing to change the referenced DLL between builds?
The difference between the two editions is due to SQLite since it uses unmanaged code. If you are not using the SQLite provider, it doesn't matter and you can use the same version in both environments. If you are using SQLite then I am not sure how to do this, but I gather most people will use SQL Server in production so won't really run into this issue.
Hope that helps.
I had the same problem, and not using SQLite was not enough to make it work. I tried removing all configuration for SQLite.
I noticed that the SQLite dll was published with my project, so i removed it from the folder containing the Elmah dll. Now my application works in both 32-bit and 64-bit.
I have an ASP.NET MVC web application which integrates a C# managed library of ours that loads unmanaged plugins to do some file processing. These unmanaged plugins in-turn rely on a few 3rd party libraries to do their dirty work; some of which are causing IIS to crash.
We use the exact same library in a desktop application which is able to process the files just fine. The files also process just fine when running under the Cassini web server that comes with Visual Studio 2008 (IIS and Cassini are running off the same folder on my local box).
I've done a Crash Analysis with Debug Diagnostic (img) which I'm not able to extract any useful information from.
I used procexp a bit to see if there where any failed file or registry access attempts that might be causing an issue but came up short. I didn't see any but could have easily missed them considering the number of lines produced in that kind of logging.
I configured the application pool to use a domain account and made that account an Admin on my box thinking it might be a permission issue but no luck. Are there other access restrictions in IIS that I'm not aware of?
Suggestions? Articles? Tools? Voodoo?
EDIT: I was able to debug this down to the 3rd party library's initialization routine. Since the library works fine running under other hosts I suspected either a permissions issue or memory issue. It turned out to be a stack size limitation when running under IIS. See Stack sizes in IIS - affects ASP.NET
Sounds like you should try and enable 32-bit applications in the application pool. Interop doesn't play nicely with binaries compiled for 32-bit if you're running 64-bit.
Is there a way to create an installable (ideally XCopy installable) version of an ASP.NET MVC application that will run in a standalone fashion on a Windows XP machine?
I don't mind installing SQL Server Express for this purpose, so I guess the question boils down to this: Can the Cassini web server that comes with Visual Studio 2008 be bundled with the application? Or are there other options?
NOTE: The installation is for demo purposes only, so there are no licensing problems. Also, I am suggesting Cassini because I don't know of a way to install IIS7 on Windows XP. I can't do major hackage on the registry to get this to work.
Not sure if it'll help, but you could definitely check out the UltiDev Cassini Web Server, which can be bundled with your app and should support what you need.
You can package, embed, bend fold and spindle CassiniDev with my blessings.
I have been told that it suits this purpose admirably.
I think this is a bit old, but check out http://msdn.microsoft.com/en-us/magazine/cc188791.aspx.
Also, the ComponentArt demos run on Cassini.
My company makes a product for this purpose called the Neokernel Web Server which includes several features that are missing from cassini like SSL support, logging, multi-threaded request processing, and the ability to start/stop/configure the server from your own process.
A free 30 day evaluation license is available for testing and evaluation purposes.
http://www.neokernel.com
I have an interesting situation where I need to deploy an ASP.NET MVC app to a (pseudo-boss's) local desktop machine so they can run it locally for data entry purposes. What would be the best way to get the app running on a vista machine without Visual Studio installed?
Ideally, It would be a one click that started a development web server and opened the page up in the browser.
I considered installing Visual Web Developer and then tricking it's dev web server into running the app, or even installing mono, since it has the nice 'start xsp here' feature that even a non-technical person can understand. The big thing is that this person is not very technical, so it needs to be easy for them to start and stop the application.
You need IIS installed, which should be available for Vista. Then just set up a working directory and put your app there, it's not 1 click but maybe.,.. 5.. :)
What about the Microsoft Web Platform Installer? You'd still have to add your own application, but it takes care of .NET, IIS, and dependencies.
Could you use something like UltiDev Cassini: http://www.ultidev.com/products/Cassini/ and build your own installer to set everything up for your user?