I had two applications that was able to run on my local machine in asp.net through visual studio. A webservice and a web forms app. I decided to try and deploy the webservice to my web host online, but it didnt work, so i tried to remove the reference i had to the MySql data connector and then move it to the "bin" folder and re-reference it. This resulted in that my local application broke, and when i tried to undo what i had done, it just remained with the same error. I have tried to uninstall and install various versions of the MySql connector, but without luck. The reference to the MySql connector also got broken in the web forms app, which i didnt delete the reference in, so now neither of them runs.
"Adgang nægtet" means "Access denied".
Here is the error for the webservice
http://pastebin.com/81wuP68j
And here is the error for the web forms app
http://pastebin.com/LVuUy9Yg
Is there any way to start from fresh? I read on a related question, that a guy suggested to reinstall windows, but that isn't a viable option at all.
EDIT: Apparently when i was re-referencing to a new MySql dll file, it was a wrong version of it, so after installing a new one (a second time), and moving it into the bin, and referencing to it, it worked.
Does the shortcut in the Start Menu set the working directory
correctly? (I suspect that this is the most likely answer)
Is there a different/incorrect version of MySql.Data.dll installed
in the GAC (Global Assembly Cache)? I've seen this give similar
error messages before.
Set 'Copy To Local' the Mysql.Data.dll reference from properties.
If MySql.Data is a mixed mode (native and managed code) 32 bit DLL.
And you executable specifies "Any CPU". On a 64 bit machine with 64
bit .NET this will fail with error message you got. A solution is to
specify "x86" as target for the executable.
Related
I am suddenly seeing this error when running my app (published on Azure app service:
Could not load file or assembly 'Microsoft.SharePoint.Client, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified. at SharePointLibrary.SPClient.GetAllUsers()
at ADVWKSP.Managers.UserManager.GetUsers() in C:\Users\bassie\source\repos\TFS\ADVWKSP\ADVWKSP\Managers\UserManager.cs:line 21
It runs fine on my machine, and it used to run fine after publish but now it just suddenly starts crying about this file missing.
I checked in Kudu and I can only see the SharePoint.Client.Runtime:
Why? How can I ensure that all required libraries are published with the project. Why did this suddenly stop working?
The hosting environment of azure web app contains a standard installation of .Net framework 2.0 to .Net framework 4.5.
If your application referenced assemblies which is not build in .Net framework, you have to "include" them with your deploy package.
Even these are Microsoft assemblies.
Setting the Copy Local property to True for the referenced assembly may fix it.
1.In Solution Explorer find your project's reference to the library.
2.Right click and choose Properties.
3.In the Properties window set Copy Local to True.
As you said, it works locally on IIS Express, please try to deploy your website content manually to Azure via KUDU or FTP client and find out whether it works or not.
Adding the following parameter
/deployonbuild=false
to the msbuild command line fixed the issue.
I faced the similar kind of issue when my app service function version was 3, but function source was targeted function version 4. updating the app service sorted the issue
I have a multi-project solution (C#) that I am trying to deploy to one of our test servers. All the projects are being built for x64, with the 'Prefer 32 bit' disabled where applicable.
Some of the projects reference a SQLite dll set that uses the SQLite Encryption Extension (not managed by nuget). When I build and install the solution on my local dev machine, the application and windows service are able to function properly, no problems.
When I try to install the same package on one of our test servers, running 64-bit Windows Server 2012, I get the "Unable to load DLL 'SQLite.Interop.dll': The specified module could not be found." whenever I try to communicate with the SQLite database. I have triple checked that all the appropriate DLLs are in the program folder after installation.
In my VS solution, I have tried creating the x86/x64 folders, setting Copy to Always, but to no avail. I have also copied the DLLs from my local install folder into the server folder just to see if something got messed up along the way.
Could it be a permissions issue? I'm an elevated user but not a full admin on the server, whereas I'm a full admin on my machine. I've tried manually modifying the permissions on the program folder to see if that was an issue, but had no luck with that either.
So to summarize, the project is being explicitly built for x64, it has the right DLLs in the right folders, and it works on a local install. I'm at a loss as to why it won't work on the server install. I've looked through countless threads on StackOverflow, MSDN, and SQLite's website, all usually suggesting the x86/x64 folders, but that hasn't been working for me. I'm hoping someone can help me out here.
Thanks!
Was actually able to figure it out after a bit more debugging. The Visual C++ runtime that was installed on the server wasn't the right version. I added the Merge Module to the installer for the version my project was expecting, reinstalled the app on the server, and now it's working beautifully.
For those who have this issue, look for the right version of the VC++ runtime in C:\Program Files(x86)\Common Files\Merge Modules. If you don't know what version you need, use something like dependency walker on the machine that is throwing the error. Mine told me I was missing VC140, so that's the module I copied into my project and added to the installer.
I'm trying to publish a project to an Azure Web App via Visual Studio 2015. This is an MVC 4 targeting Framework 4.6.2. The publish procedure claims in VS2015 to have finished successfully, however, when the browser is launched to display the published site, it errors out with a 502 error (bad gateway/proxy) on the favicon.ico file. Obviously, that's not what's really happening.
I downloaded my eventlog.xml file from the Web App and looking at the error being reported, it's claiming that it's unable to find assembly 'EntityFramework, Version=6.0.0.0...'. However, I see the EntityFramework.dll contained within the project bin folder. But, just to see if it made any difference, I tried using Kudu to install EntityFramework from NuGet, as well as doing a nuget restore using the packages.config file that was successfully pushed up to Azure. All that did was restore a ton of files where I didn't need and the same error remains.
Has anyone else seen this issue and have any recommendations on how to resolve it? I'm not sure what else I can post to give a clearer picture of what's going one...it's not like there's any code or source, and the eventlog.xml file shows little more than the YSOD error message for a missing assembly.
Please, any assistance would be greatly appreciated!
I've had this in the past - if you read the error message carefully it says it can't load that assembly or some of its dependencies - so it may well be another dll that's missing from your application.
Use the Console blade in the portal (or the separate Kudu site and console if you prefer) to compare the bin folder contents with that on your dev/test environment and see what's missing - if you stick to using nuget packages then you shouldn't be able to go far wrong, but I think I still had problems a while ago with EF when I didn't reference the EF libraries directly from the web app, but only from a repository assembly that was referenced from the web app.
If you're not using Nuget and referencing the dependencies directly make sure the referenced dll's "copy to output" properties in VS are set correctly, such that the dll's end up being copied to your project's bin folder and included in the package that gets deployed to Azure.
Well, it turns out this one was one of those "that's not the real issue" error messages. Thanks to Russell and Karel. You input led me to verify a few things and make sure I had all things referenced properly.
Here's what I found out...our DEV SQL VM is turned off on the weekends to conserve resources (aka $$$). After sending all files from my local bin directory via FTP, I browsed to the site and received the same error. Downloading the logs, however, showed that I couldn't reach the db server using Named Pipes. Whoops...one of the connection strings (in the repository project) had not been set to the FQDN, so it wasn't using TCP/IP for the connection.
I fixed that, published the site, turned ON the sql server, and now the site is working as expected.
Moral of the story, make sure you have all connection strings set properly.
Alright, so I've got a Windows service that has a FileSystemWatcher that watches an output folder for some Visual FoxPro database files. And it leverages the VFPOLEDB.1 provider to read those files. I cannot go away from this provider because it's being used in production.
However, I've never had to support this application before so that's why my development box isn't setup for it. Here is my environment:
Windows 7 x64
Visual Studio 2005
.NET 2.0 Windows service
so, when I first started getting the error I figured I just didn't have the provider at all, and I was right. So, I downloaded and installed it from here.
I then proceeded to drop the files in the folder again, but I got the same error.
I figured because it's an x64 machine I might be experiencing problems with it getting registered since it was probably dropped into SysWOW64, and it was as I expected, so I ran this command:
regsvr32 "C:\Windows\SysWOW64\mscomct2.ocx"
and it said it was successfully registered (which means about nothing LOL) but I dropped the files in again - same error.
I have not yet rebooted my machine, and I can if somebody has a compelling reason that's the problem, but generally speaking if the assembly is registered properly with regsvr32 that's not necessary. I've worked with a ton of COM objects and never have to reboot to get to the object as long as I've registered it.
Does anybody know another step I need to perform to get this thing registered?
It is registered as it should. It is your application that is compiled for AnyCPU Platform.
In x64 operating system this produces 64bit code and 64bit code could not access 32bit drivers.
Change your Platform to x86 and you will be fine.
EDIT
Two years later there is something to add to this answer. Now with Visual Studio 2013 the cheese has been moved. The article linked explain in great details how the compiler setup defaults has been changed. The AnyCPU target CPU with Prefer 32 bit means that your application works as 32bit app also in x64bit operating systems leaving practically no-room to x64 application unless specifically required.
With this new configuration becomes also important to remember what is posted in comments below by Mark Berry. If your (now 32bit) app needs to work in a IIS 64bit environment you need to set the Application Pool with Enable 32 bit Applications
I have desktop app (Win7 x64 VS 2015) - and kept getting the same error no matter what. I changed platform target to x86, installed MSI as admin etc - did everything I could google - and no luck. What helped me is to install MSI for Everyone instead of Just me - one of the last wizard's screen in the setup.
I have the same problem.
I install the VFP Ole DB Provider in my system and resolved.
download link
use Advantage OLE DB Provider,works for 32 or 64,here is the connection string
I'm currently working on a program in C# WPF. I use an external dll called Irrklang. It's made for x86 only so I set VS to compile for x86. I added the reference, set the copy local to true and set the dll as Required in the application files.
When publishing the app using clickonce I upload it. I install on two machines: my dev machine and another machine. On my dev machine things work fine. On the other machine I get the could not load file or assembly exception through my error handling I added to my app. In the event log there is a xamlparse exception.
How can I solve this when everything works fine on my dev machine. I tried Dependencywalker but that doesn't show anything and I made sure the dll is in the folder of the executable. I ask this question again here on stackoverflow, the last time someone made me an empty app with a reference to the dll and he installed it on 3 other machines and it worked fine. I published his app like I did with my own and it shows the exact same problem!
Please help me out
UPDATE: I was thinking about it but your comment beat me to it! :D I program .net 4 Extended and it is set as a prerequisite. VS C# Express 2010.
Well, no specific advice then. It sounds like you just need to some old school trial and error... Whiddle the app down to something that will distribute correctly with ClickOnce and keep adding functionality until it doesn't!