I'm getting this error whenever I try to debug the Azure project from Visual Studio. I checked on my original site project file the Platform Target and project's and every dependence as well are using "Any CPU". Not really sure what to do from here.
Could not load file or assembly 'Pechkin' or one of its dependencies.
Are you running 32 bit allowed? Lots of docs out there talk about this being a limitation.
mark as the answer please if that is the problem. There are solutions as well. apparently a guy did a fork called tuesPechkin with 64 bit versions.
It's not possible to get wkhtmltopdf working on Azure. See this thread and this Gitgub issue.
I am assuming you mean running wkhtmltopdf on Windows Azure Websites.
wkhtmltopdf uses Window's GDI APIs which currently don't work on Azure
Websites.
A solution could be to create a Windows service (or for example a web api endpoint), which runs the Tuespechkin converter. Then create a VM in Azure and install the Windows service/end point there.
Related
For an app for Windows 10 IoT Core on Raspberry Pi2, I need to use a launcher app or StartUp-Task, which creates a shadow copy of my app and launches it. I need to use this approach to be able to substitute DLLs during runtime, without having a lock on the DLLs and without disrupting running services. That's needed as the device running it, would be remote somewhere out of reach, deployed at a client's site and I need my app to be running to service the device. After updating my DLLs, I would restart it and it would run with the new libraries, start the launcher as default app, which then starts my app.
Before Windows 10 and UWP the approach was to use System.AppDomain from mscorlib.dll in the .NET Framework to create a new AppDomain in a cached directory. The config, executables and DLLs would be copied to a cache directory and run from there. That leaves the original DLL available for substitution and doesn't put a lock on them. This was also a very useful technique used in IIS and webapps, which needed to run without interruptions even if the code needs updating. The open threats keep servicing open requests until these are done and new requests will be serviced using the new updated versions.
Now in Windows 10 System.AppDomain is not available anymore. I tried Windows.System.ProcessLauncher but encountered several issues with it. First I have to register the EXE in the registry to allow launching it. Then it tells me I can only run it from an app container. I didn't get it to work as of now. It's just a tedious and messy approach IMHO.
Now to my question: What would you use as an alternative to the described old approach on Windows 10 IoT Core? Does anyone have a small snippet of sample code to share? Or perhaps a link pointing in the right direction? Any advice would be appreciated.
This approach is not compatible with the Universal Windows Platform app model.
You will have to push an updated package of your app.
When I open a sample Blinky application in Visual Studio, compile and run it, it gets automatically deployed to the target configured WindowsIoT device. After that, on Windows 10 machine where I compile it, the application binaries are located in the bin sub-folder of the project folder as one would expect.
I would like to automate the deployment, so that I could run deployment code
without Visual Studio, specify target device and the binaries location and it would deploy it. I cannot find any API that allows
to deploy apps to Windows IoT, how do I do that?
This shiny Windows IoT stuff is a new area, and there is not a lot of info available apart from the samples and the getting started page. Any pointers are appreciated.
Update: As noted in comments, once one start thinking of mass production, they will probably need to conciser ICD. This, is not, however the problem I'm trying to solve currently. I would like to figure out how I can provide Over-the-Air updates to my UWP application running on Raspberry Pi and Windows IoT. I also would you like to know how I can automate build / deployment in general, but that may be automatically solved if I have a proper OTA solution.
There is a set of instructions on how to do it, which can be found in the same github repo you are linking in your question, but in a different folder. Note, that you need an appx for these instructions to work, and it's not created by the solution build by default.
This page provide (non IoT specific) instructions on using VS to build the appx. And this blog post talks about the command line tool that can be used for making appx.
Note, that the last two links are also talking about publishing an application to app store, so you'll need to make some mental adjustments around that.
I new to ASP.NET development and I have managed to deploy VirtoCommerce to my local machine IIS (windows 8.1) following the documentation on http://docs.virtocommerce.com/display/vc2devguide/Deploy+web+applications+to+dedicated+server .
When I tried to deploy it in Azure VM running Windows server 2012, I got the following error when I tried to run the frontend page. The dll mentioned below is definitely in the /bin folder of the store.
Server Error in '/' Application.
Could not load file or assembly 'LibSass.x64' or one of its dependencies. An attempt was made to load a program with an incorrect format.**
I followed the link
Could not load file or assembly 'LibSass.x64' or one of its dependencies in VirtoCommerce but found no luck. What did I miss on this deployment ? Any help is much appreciated, thank you.
Are you running 64 but machine and IIS Application Pool as 64 bit? If not, make sure to go to IIS and configure pool settings to run as 64 bit process. The easier approach will be to follow the guide here: http://docs.virtocommerce.com/display/vc2devguide/Deploy+from+GitHub+to+Microsoft+Cloud+Azure which will setup Virto Commerce as a website in IIS with all correct configuration for IIS. You can then update it manyally by simply uploading site through FTP if you want. You can also clone the repository on GitHub and that way your azure site will auto update on every checkin.
I was able to reproduce this error on a clean Windows Server 2012 Standard. It turned out that Libsass.Net requires Visual C++ Redistributable Packages for Visual Studio 2013. After installing the vcredist_x64.exe the error has gone.
I have an application that connects to a DB, extracts info, creates a excel file, and then drops the file/emails X people the file.
The application was created in Visual Studios using .NET 2.0 Framework (Windows Form App). It was run on a 32 bit server. But it recently was moved to a 64 bit server. It is now returning with the error message " The 'MSDAORA.1' provider is not registered on the local machine."
I believe that MSDAORA is only supported for 32-bit applications and the Application Pool the app runs under in IIS is not enabled for 32-bit applications.
How would I fix this issue, is there something I can change in IIS? Or is it a code change?
Using ORAOLEDB.ORACLE rather than MSDAORA fixed the same issue for me - changing the platform target from 'Any CPU' to 'X86' caused errors within my project in Visual Studio.
See answer here
I figured out the solutions for this. The problem stemmed from running the machine on a 64bit machine. To change that in VS, open up the properties page of the solution and in the build tab change the targeted platform to x86. And that did the trick.
http://lostechies.com/gabrielschenker/2009/10/21/force-net-application-to-run-in-32bit-process-on-64bit-os/
Thanks for your help Yuriy.
I had the same issue, but I used another solution because my application is running in IIS.
In the advanced settings of the application pool I changed the value for Enable 32-Bit Applications to true.
I had he same issue but it wasn't 32/64bit. I used the ODAC xcopy installer and forgot to run it in a cmd.exe as administrator. It didn't give any error so I had a hard time figuring this out. The xcopy part worked but the DLL registration via regsvr32 silently failed.
https://learn.microsoft.com/en-us/sql/ado/guide/appendixes/microsoft-ole-db-provider-for-oracle?view=sql-server-ver15
11/08/2018
This feature will be removed in a future version of Windows. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Instead, use Oracle's OLE DB provider.
so probably using ORAOLEDB.ORACLE is the correct solution, but that seems like more effort than just changing the connection string.
I am working on a Web Application on a Windows 8 64 bit machine using multiple existing libraries. I want to use two C# DLLs referencing one native DLL. Both C# DLLs are compiled for 64bit usage and tested in test applications.
My web application references both C# DLLs and is supposed to run on IIS 8.
I added the two C# DLLs as references to the project and the native DLL manually to the bin folder of the web app. Whenever I build and run the solution I get the exception shown in the title.
I know that this is a sign for a problem regarding 32 bit and 64 bit code running in one process. Therefore I tried all different build configurations but the result never changed.
I created a console application doing exactly what I'm trying in the web app and it worked flawlessly.
The Web application with the exact same settings however throws the exception, this is what is really confusing to me.
What I tried so far:
Change application pool setting to "enable 32-bit applications"
Build all DLLs with Any CPU, 64Bit or x86 target
Check the corflags of all DLLs
I can provide an export of the project to everybody willing to help me get this configuration running!
I really appreciate every bit of help!
I presume you tried with setting Target Platform (Build option in project properties)?
Also, take a look at this article:
http://www.codeproject.com/Articles/383138/BadImageFormatException-x86-i-x64
I got the same issue on my application. It was fixed after I perform the following:
* Granting permission for the "Anonymous" user in my web site folder.
* Changing the application pool from ".NET v4.5 Classic" to ".NET v4.5".
All I can offer is some help in determining what isn't loading. If it's a dev server it might be worthwhile to install the appropriate sdk to use the Fusion Log Viewer. If that isn't an option you can turn on assembly binding logging from the registry as follows:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"LogFailures"=dword:00000001
"LogPath"="c:\\bindFailureLogs\\"
just be sure to turn it off when you're done, there is a performance penalty using the assembly bind logging. Make sure the folder exists before you enter the registry key and recycle the application pool of the application for the logging to start. This will provide you a detailed list of what dll (or dependency since it's not always readily apparent if it's a dependancy or the dll listed in the error message) didn't load and where it tried to load it from.
Your partitioning of the applications fixing the problem suggests that there are multiple dependencies on the assembly targeting different versions and since only a single version of an assembly can be loaded into an app domain some dependency isn't being satisfied. For managed assemblies you could use an assembly binding redirect, but I don't know what the unmanaged equivalent of that would be if it even exists.