I have two apps that use the Microsoft.ACE.OLEDB.12.0 provider to open Excel files on the same machine. One routine is a c# compiled app that works fine..the other is a non-compiled asp.net app that uses vb code behind that we are trying to re-host that throws 'The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.' errors when opening the Excel file - which appears to me to be bogus since the other app runs fine on the very same machine. I have checked the app pools for both and they appear to be set up identically...they both have 32 bit checked and are using the same .Net framework version. The web.config for both of them has the same connection string with the same options (only difference is the name of the connection)..We even re-installed the dll. I tried copying the dll to the bin folder for the aspnet app, but no luck there either. I would compile the asp.net app, except it uses ColdFusion for part of its output... I am hoping there is someone out there that has run into this particular issue and might have some pointers on where to look to solve this... Or maybe a different direction?
Related
I have basically installed the default Blazor WebAssembley template, with .Net Core server.
Ran the app, worked fine, comes with the initial migration for identity which ran and created the database tables so I could create an account login etc.
Changed 1 view file razor file and now the app will not run. In debug mode I can see the it seems to be empty, so the application falls over when it tries to connect to the DB with an empty connection string.
I just ran through the exact same steps on another machine and the same result, yet the only files changed are the appsettings.json and a razor file.
appsettings worked fine, then without changes no longer works. Any suggestions on where to investigate would be appreciated - this is my first step into .Net Core.
So just in case anyone else comes across this problem. I had the application open in another browser window, although I was not interacting with it.
Once I closed all the browser windows and ran the application again I no longer had the issue.
One thing to note, I am running IIS Express with the option "Do not start browser" so that VS does not keep closing and opening a new browser window.
I am deploying our system to a brand new server that was previously untouched and having serious issues with .NET (the error points to server controls but i think this is a symptom rather than the problem)
Basically the VB6 code seems to work correctly but when moving over to the .NET I keep getting a parser error when loading the server control.
Like this
Im quite sure that the server control isnt the issue and there isnt an issue with the compiled code. I have copied the code over from a working deployment on another server.
The code is organised as a WebSite rather than Web Application
The control is referenced at the top of the aspx page like so
<%# Register Namespace="CustomWebControls" TagPrefix="Fastrack" %>
CustomWebControls is in the App_Code folder and is compiled into App_Code.dll
I think there is some issue with windows or IIS config stopping the reading of the compiled app_code.dll file. I have checked user permissions and allowed all to access i have manually copied over the dlls to the asp temp folders.
Other things tried
reinstalled IIS
reinstalled .NET
checked web and machine.config files against known working ones
checked iis installed components are correct
I'm completely out of ideas with this one and I'm not sure where to go next.
The stack trace disappears off deep into System.Web.UI and doesn't hint at any issues with our code at all (doesn't even seem its getting as far as loading it)
Platform
Windows 2008 R2
IIS 7
.NET 4
ASP.Net webforms
If anyone has any suggestions or would like some more info from me let me know.
After much ripping out of hair and sleepless nights the anser was a missing precompiledApp.config file!
The hardest ones often have the simplest answers!
Appreciate help on below issue where we are using a decryption program written in .net from a web application to decrypt and encrypt files on server.
This program is working fine on Windows 2008 server when launched from command line. However when we are calling the same program from Asp.net code in an application hosted on IIS 7.5 --> Its not working at all.
Its not even showing any error. Even checked event logs. It simply does not decrypts.
Please note we are using ProcStart to launch this decryption program and passing necessary parameters. The Keys are well places on server in a local folder and the exe file with required config files is placed in another folder on server. All these folders have been provided full access to everyone right now just to make sure there are no access issues with files when accessing through IIS.
Also, the same program works fine when we run the site in debug mode on server (from visual studio after logging with localadmin).
Please help if we are missing some settings somewhere which are not allowing the decryption program to work when launched by a web user from website.
Unless we have any error it is difficult to troubleshoot but can you try to configure an apppool with some user/system idenitity. Give that identity full previledge on files to encrylt/decrypt and program. Run your asp.net website using this configured apppool.
Situation:
We created an assembly with our own ASP.NET control.
That control registers some resources (images, JavaScript files, etc);
There is a web-application which uses our control.
The control is loaded well and get access to internal resources. In result HTML code all calls to resources look like "/WebResource.axd?d=...".
So far, so good.
We have two computers: first - Win7 32 used for development, second Win7 64 - for testing.
The problem:
The assembly generated on Dev machine works well on it but give 404 error for all requests to WebResource.axd when running on Testing computer.
If we just copy the sources to Testing computer and build our assembly there - it works well on both computers.
We use .NET 4.0. All latest updates are installed on both computers. Web application which uses our control runs right from VS 2010 (under ASP.NET Development Server).
Any suggestion?
We've found the problem.
Our testing computer had wrong date/time set (10 days before the real date). So our assembly (built on development system) was considered by it as a "DLL from the future".
And it seems ASP.NET can stand the assembly "from future" but it does not like "future" resources placed into that assembly.
Once we corrected date setting on the testing system - everything started to work well.
Hope this case will help somebody else.
The assembly with your asp.net control may not be included in your web application deployment.
Look for the reference to your assembly in the web application, right click it and select properties.
Look for the copy local box, and set it to true.
recompile the application and redeploy it to the other machine.
I have C++ project that compiles as DLL Assembly in .NET 3.5 SP1
Project is used for Image rendering processing by using WPF (it loads 2 images from local folder, applies one image on another and saves the output file in the same folder).
I want to use that that project as a reference in ASP.NET project to the rendering on the website.
So I created simple Web Project in ASP.NET C# that uses C++ project as a Reference.
Everything works great in ASP.NET Web Development Server (built-in Web server in VS2008).
But once I publish this project to IIS on the same Machine or use IIS for debug instead of built-in Web server Image rendering it's not working anymore. I'm not getting any exceptions or error messages, it just output image is not processes as it supposed to be.
If anyone know what could cause that I would really appreciate your insight!
Do you have access to the Event Logs? You should check there for any errors. You should try to throw an exception from a C#-only code path and make sure that everything is OK and regular exceptions are being thrown. Is the C++ compiled to managed code, or is native code? You might find that ASP.NET does not have the appropriate code access security permissions and needs to be registered in the GAC of the server to accessed from C#.
You should also check whether the DLL is thread-safe. This has caused issues for other users in ASP.NET/IIS.