I have a very strange issue that i cannot figure out.
First i have a WCF service 4.0 done in VS2010.
the service have couple methods that return string array, datatable and such.
some of them use function from C++ dll throught [dllimport]
i made a test console to test everything. when i run the WCF from visual studio and use the generated path it works wonderfully.
now here is where it become strange. if i open my local IIS create a new application and point to my VS source code the WCF i can see it perfectly.
now using the http path from IIS local instead i refresh the methods all seems correct. But when i run my test app i can call any unction without any problem EXCEPT anyone using DLLIMPORT functions. they ALL crash and cannot trace even by tracing CES exceptions.
Doing line by line logging show that the exception is really on the call of those functions
the DLL in question is the same and the path is hardcoded for my computer since still in test phase and the folder is c:\DLL\mylib.DLL so nothing to do with shadow copy IIS/visual studio do when you actually run. also DLL reference by name withotu path even if it's in sys32 doesnt work.
Any clue ?
also. 32bit, changing app pool level right access on folder, full admin on machine already too. all tried but unsuccessful.
Edit: adding to all that since i haven't made this clear, it's not my first WCF real setup. i've already made alot of services before and deployed them myself (probably somewhere around 50-60 services). I am asking because i have never seen this issue before and i tried all tricks i knew and could find on the internet and resource people i know.
We have decided to incorporate the whole service in the WPF project locally since it work as long as IIS is not hosting. but this is really not a good thing as this data and work should NOT be done on client side but instead on server side. Right now it's fine since the software that need to use this is not released to public yet so it isn't critical.
Next option will be net TCP/IP windows service hosted on the web server if i don't find anything else.
We decided to go trough the trouble of having to hard code the logic in the main software and get away from web services for this issue. we will have to deal with updating, installing unregister and re register unmanaged DLL by hand somehow but at least it works.
we have added over 5 web services since that happen and no problem with them but again none of them use DLL imports.
Related
I've inherited a Silverlight/WCF application. (Having worked on .net MVC, and SPA for quite a while)
I tried switching the IIS website folder to see if a tweak to the code and a fresh build would work, it didn't work and I switched back and although the website is functional it has a number of faults.
For some reason the Windows authentication appears to have stopped working, this authorises a number of the admin functions. I think this is broken and so not enabling the functionality in the Silverlight app.
The server I've inherited has the applications as folders in the default website, which is new to me, and quite constraining. I've gone through IISAdmin videos, and learnt a lot, but not enough to fix the issue.
I am unable to get the software to run in VS2013, quite a bump after working on Single Page Applications.
I'm stumped as to how the same code put back no longer works; I've learnt my lesson, but I still need to fix the system. I am not sure whether IISReset would make a difference since the AppPool is recycled every 29 hours. I've found out what the harm in trying is, and so I am proceeding with caution.
So my main goal would be to get the Windows Authentication working again.
I'm somewhat new to deploying ClickOnce manifests, first off. I know the basics of how to publish to an app server, which then lets every use the newest version (after setting to check for updates before running the application).
We have multiple VB.Net applications stored on our app server, that cover a lot of different areas of the company. However, all of them connect to our Oracle database in the same way. So, my thought was to create a DLL containing commonly used functions, such as decrypting and reading our connection string, among some very common SQL functions/statements that we use a lot. Then, instead of copying and pasting the same code into each .Net program, it would be stored in one place. Of course, the major benefit to this would be that if we change the method we use to connect to the database, or need functions modified/added, we don't need to open each program, paste it in, and .republish
So, I did a test where I took a program that I wrote, added the DLL to it and tested it out. It works great. Then I took the source code of the DLL, made a change to show a message box at the beginning of a function, rebuilt the DLL, and dropped it in place of the copy that was being referenced in the test program. When I run the program, it's still using the original DLL without the message box code.
My question is, how could I accomplish what I would like to do without having to republish each and every .Net program that uses this DLL whenever a change is made to it?
Option 1
Instead of publishing your dll library via click once, Put a web service wrapper around your dll class library. Each Click once application will have a reference to the web service which will run on a web server.
Your code in the dll will then be running on the web server. Any changes to the dll code will only need to be updated on the web server. You'll have to be careful to keep the interface changes to a minimum.
Option 2
push out the dll as an separate MSI install. Reference the dll in your click once apps code and make sure you don't deploy the dll with the click once install. Changes to the dll will be pushed out separately.
Forgive me if this is a stupid question, I'm fairly new to writing services. I've written a service that runs a timer and the timer code runs some checks to ensure our systems are up and running. It's written in VB.Net, framework 1.1. I then install the service using "sc create". The service works beautifully on the XP Pro machine that I'm developing on. However, when I install the service on a Windows 2003 server 64 bit, the service fails with error 1053 immediately. I put some debugging in to write to a text file as the first line of code in the OnStart function but even that doesn't run, so there must be a problem in the program starting up. Finally in desperation I created a brand new Windows Service in a new VB project in Visual Studio 2003 and compiled an empty service that merely declares and sets the value of a string variable in the OnStart function as follows:
Dim strTmp As String
strTmp = "hello"
Even that failed on the W2K3 server, but works fine on the XP dev machine.
The server has .Net Framework 1.1 installed and working, we use it in our CMS (written in ASP.Net 1.1).
The service runs as the local system account. I tried enabling interaction with the desktop but that didn't help. I ran Process Monitor and there are no access denied events. I emptied the Application Event Log, still doesn't work. No other events to help me out in the logs. Definitely using the Release build of the application. Permissions on the exe file are full control for System and for Admins.
Any ideas anyone? It must be something simple, but I'm damned if I can figure it out!
Thanks in advance.
#DavidHi, many thanks for the suggestions. I don´t think the first point is my problem, partly because the MS article is about stopping or pausing the service, mine fails on starting; but also because the service does not timeout, there is no 30 second wait, it fails immediately. Secondly, when you say add an exception handler to the service startup, do you mean the OnStart sub? I tried adding a debug file write in there, but I'll try adding an event log instead. Regarding the systems checks, it can't be that because the brand new empty test service I created shows the same behaviour and that does not do anything at all. You last point could be the key. My dev environment IS 32bit. I'll do some research on the corflags thing, or perhaps I can build a 64bit dev environment. Many thanks again, you've given me some new things to think about at least!
Ok, have found a workaround. I was putting my exe file in System32. When I put it in a different folder, created by myself, the service ran, albeit briefly. I then had to move the ini file and the log files that it reads/writes to that folder too, rather than System32, and all seems to work nicely. God knows why it doesn't like running from System32 but at least it works now! Thanks for the help guys.
This looks very similar to this question which might help you out:
Starting a windows service fails with error 1053
A couple of other things to look out for:
Make sure you don't have either of the following statements in your deployed service:
System.Diagnostics.Debugger.Launch
System.Diagnostics.Debugger.Break
You may need to run the service with an account other than Local System (depending upon the permissions required by your service).
The 1053 error is a timeout related to the service control manager waiting for the service to respond to your start request. There is a knowledgebase article that refers to managed service stop request issues specifically relating to Framework 1.1-based services, so it is not precisely describing your problem, but it may have relevance in your situation. The link is provided for your reference.
http://support.microsoft.com/kb/839174
The other suggestion I would make to further diagnose the issue is to determine whether the Start is failing due to a "hidden" exception occurring in your service's startup code; the start call would not see the exception and could make you think it was merely timing out.
I would suggest you add an exception handler to your service startup that does nothing more than log a message to the event log with the particulars of the exception if one is caught. That would at least give you an idea that something is going wrong specifically within the service, and give you more information than you have right now.
One last thought: Does the service check the systems you describe over a network connection? If so, LocalSystem won't have sufficient privileges to perform network access.
Good luck!
EDIT One other possibility:
Is your development environment/execuable 32-bit? You mention your server is 64-bit, so you may need to use the "corflags" tool that forces 32bit operation on your executable
corflags /32bit+ YourServiceExectubable.exe
The source for this information was the following SO post:
32-bit Windows services in 64-bit environment
**Unfortunately, it appears corflags is applicable only for 2.0 assemblies, and was designed for specifically this type of problem. **
i have an application written in VFP 7, somewhere in the application i call a function in a dll using the following :
declare long FunctionName in DLL_NAME.dll string#, string#
.
.
.
RETURN FunctionName( StringParam1, StringParam2)
calling this function generates an error :
The following error has occurred:
Message: Cannot load 32-bit DLL d:\folder\DLL_NAME.dll.
i tried registering the dll using the 32/64 bit regsvr...no luck !
Info that could help identify the problem :
the dll file is not local, it is in a folder in a network mapped drive.
thank you very much for your help.
Aside from VFP not supporting anything 64-bit, I would look at the fact you are trying to load a dll across the network.
Eliminate that as a possible issue and copy it LOCALLY and load it from that...
Try to eliminate everything ELSE, including your VFP application. I would start directly from the VFP command window and do nothing but have a simple .prg file. In it, put nothing but the declaration and reference a LOCAL copy of the dll file. Set the values for your parameters, and then call the function.
If that doesn't work, then it doesn't matter WHERE in the application its being called... you've just eliminated that whole set of conditions and environment.
Its almost like support I offer to clients sometimes when trying to do something in our app that requests data from the internet. I have them manually go to their browser and put in whatever URL our app would be trying to go to. If they can't get to it from the browser, its something from their firewall, IP blocking, or other... it has nothing to do with our app. You might be running into a similar situation. Leave out all other elements and just get the few to absolutely test the problem isolated to itself.
I agree that the issue is likely that the dlls are located on a shared network. I have solved this problem in the past by copying the files to the local machine(s).
However, according to this article (link below), you can allow a FoxPro app (or any .exe for that matter) to use dll's from a networked drive if you add a special config file that tells the .Net framework that it's okay to access networked dlls for a certain app.
Here is the link: http://www.west-wind.com/webconnection/docs/index.htm?page=_36e0qlogr.htm
Very frustrated with all of this, hoping someone can assist.
I had a Silverlight application and WCF working together without issue for a year. In order to get them working, I had some pain initially but finally worked through it with help. All of the pain came from configuration/security, 401's, cross-domain hell, etc.
The way I have everything setup is that I have a WCF service that resides in it's own application/directory and runs in its own application pool.
On the same web server (IIS7), I have another application/directory with the Silverlight application that points to the aforementioned service.
The server name (for this exercise) is WEBSERVER1. We've created a CNAME for it that is WEB1. In the past, if the user went to http://WEB1/MyApp/ or http://WEBSERVER1/MyApp/ it would work. Suddenly yesterday it started behaving badly. Normal users started getting the Windows challenge/response prompt (and even if they entered the info they would get a 401 error).
My WCF service runs in a site that enables anonymous access (and this has always worked).
My Silverlight application runs in a site that has windows integrated (and this has always worked), since I capture the Windows username when they connect.
For the record, I did create a NEW application pool yesterday with an ASP.NET application that runs in it. This seems to work fine, but there is a chance creating this new application pool and application/directory has caused something to change.
I have a clientaccesspolicy.xml in my wwwroot folder, as well as in the folder for each of the two applications above (just in case). I have tried to promote NTLM over Negotiate as a provider (as that worked for another issue I was having on another server).
After trying some changes, I can't even get the thing to behave the same each time I call it. Sometimes it will prompt me for credentials. Other times it will work, but then say it failed to connect with the WCF service with a "not found". Other times it will actually work fine, but only if I am using the actual server name and not the CNAME. When using the CNAME I always get the crossdomain error, even though I have the cross-domain xml files in every directory root.
This is a nightmare, and makes advanced algorithm analysis seem fun and easy by comparison. Did Microsoft realize how difficult they made this combination of (IIS7/WCF/Silverlight/providers/permissions/cryptic or missing error messages) to get to work??
I found a solution that appears to be working.
In this case, I had to change the authentication mode for the default web site (which hosted the clientaccesspolicy.xml file) from anonymous access to Windows Integrated. I don't understand why this worked for a year or so and then stopped, but it seems to have resolved it.
The new application that I had deployed yesterday was a standard ASP.NET web application, which I put in it's own application directory and it's own application pool, to ensure that it would not cause this sort of issue. I'm still not even sure if it did.
The way I resolved it was by trying to navigate from my PC to the actual http://servername/clientaccesspolicy.xml file, and that was giving me a 401 error. I switched from anonymous to windows integrated on that default website (which has nothing in it except for that xml file) and that resolved the permission issue. I then had to permission the actual AD groups to have read access to that folder (if not they got the user/pw prompt and could not get through).