Have I an application using sqlite...
Ive tried this:
installing via ClickOnce Application setup (it works)
I Put SQLite.dll file together with .exe in the same folder. (it works}
hmm the folder with an .exe only (not working)
What I mean is when you build the project and get the .exe on the folder \bin\Debug and move it somewhere then when you run the app errors will not occurs.
I wondering if there's a way that i can run even without installing ClickOnce Application setup?
I thinking of setup the SQLite.dll on specific path reference? Is it possible to do that?
-thanks
System.Data.SQLite.dll is not part of the standard .NET Framework so it does not get installed in the GAC of the client machines when .NET runtime is installed at first.
that's the reason why you should have this dll referenced by your executable, distributed together and in the same folder as your exe is deployed.
or you could distribute it somewhere else like in a sub-folder of your application setup and have proper entries in the configuration file or in the .NET C# code to specify where assemblies not found in the standard locations have to be loaded from.
You can use Nuget to get the package installed. For my case, it automatically created 2 subfolders for me, which is x86 and x64, I just followed the folder structure in the bin folder, and it worked fine for my case.
Related
C# .NET 6.0 WinForms x64bit Desktop application
Application exe runs fine via the project's "x64\Release" folder.
We deliver via an MSI created via "Setup and Deployment Tool". When the application is installed via the MSI file, the user gets an exception as the application launches.
System.PlatformNotSupportedException: System.Management currently is only supported for Windows desktop applications.
at System.Management.ManagementBaseObject..ctor(SerializationInfo inf, StreamingContext context)
I've tracked this down to a difference in the file: MyApp.deps.json between the "Release" folder and the installed destination "Program Files" folder.
If I copy that "Release" .json file to the "Program Files..." location, the application runs fine.
What's going on with the Setup and Deployment MSI creator? How can I fix this?
Runtime Configuration Files:
MyApp.deps.json - A list of dependencies, compilation dependencies and version information used to address assembly conflicts. Not technically required, but required to use the servicing or package cache/shared package install features, and to assist during roll-forward scenarios to select the newest version of any assembly that exists more than once in the application and framework(s). If the file is not present, all assemblies in the current folder are used instead.
So you'd better have it deployed with your application.
Regarding the issue. Do you use publish profile? Please check if you specified it in PublishProfilePath, as described in Visual Studio Installer Projects Extension and .NET 6.0
Also you can check what do you have in you publish folder and try to configure the publish profile to have everything you need there.
I developed an c# application using emgucv for face detection. According to emgucv documents folder "x86" or "x64" (depending on platform for which application is running) are need to be kept parallel to executing exe. So i did accordingly and run the project, application works just fine on my machine.
If I release this c# application along with all the dependent dlls and "x86" folder and copied to an windows 7 machine, after executing the application i get error Unable to load DLL 'cvextern' : The specified module could not be found. (Exception from HRESULT: 0x8007007E)
This is what i tried to solve the error:
I copied all the DLLs from folder "x86" to executing folder (i.e outside to x86 folder) and now application runs without any error.
So I am in confusion whether to keep x86 folder in executing folder or content of x86 folder. As per my observation both are working but what is recommended?
Normally the cvextern.dll file is located in the following folder:
project_folder\bin\x86\Debug\x86
project_folder\bin\x86\Debug\x64
The same goes for the x64 version:
project_folder\bin\x64\Debug\x64
project_folder\bin\x64\Debug\x64
The folder can also contain other files, e.g. opencv_ffmpeg310.dll. The Emgu.CV.World.dll and similar DLLs are located in the Debug/Release folder (one folder up).
Not sure which version of EmguCV you are using, I am using 3.2 so everything is built for x64. When I distribute my application, I create a x64 folder in the folder where the exe lives. In this x64 folder I put ALL of the DLLs from the EmguCV distribution. On my machine EmguCV lives in:
D:\Emgu\emgucv-windesktop_x64-cuda-tbb-ipp-icc 3.2.0.2682
So from the bin\x64 folder I copy everything to where the application exe is.
Doug
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 have created a simple inventory application in WPF. How should I give it to client now ?
One way what I did: I have set my AppPresentation solution as start up project and I can see all the DLLs from other solutions are added in the Debug and Release directory of this solution.
When I copy the Release folder to other drive (from D: to C:) and run the AppPresentation.exe some Error occurs about some DLL missing but I can still see those DLLs in this folder.
However when I copy the debug folder to the other drive and run the application i.e. AppPresentation.exe now I can run the application successfully with complete working.
Can I give this entire Debug folder to the client and expect that it runs perfectly on his machine ? I will ensure .NET 4.0 Framework is installed on that machine (but not Visual Studio ofcourse). Will this work ?
It will work as long as you have the required version of the .NET Framework installed on the client and all the necessary dll's have been included,
Ideally you should look at creating a Visual Studio setup project:
Using a setup project has the following advantages:
All your dll's and other files required for the application to run will be consolidated in one setup file
You can specify prerequsites such as .NET Framework which will prevent installation until all the required components have been installed first.
Users can specify exactly where on disk the application should be installed without manually copying the dlls (as would be the case in your scenario).
This is but a few advantages of using a setup project but hopefully you'll be convinced to give it a try as it is the preferred way of installing Windows applications
P.S If your setup project gets more complex consider looking at Wix
I have created a windows application and I have published it by publishing wizard.
Now I want to make it portable so that the end user does not need to install the application.
The application is very simple and the only dll it is referencing is office outlook interop.
Please let me know how can I make the application portable
You should be able to just copy the files in the bin folder and launch the app from there. This is called "XCOPY deployment", long marketed as one of the major benefits of .NET applications.
Just make sure that you set the properties on the Office reference so that the DLL is copied into the bin folder, too.
However, for this to work, the client machine must have the appropriate version of the .NET Framework installed. So it won't be truly portable unless you can control the configuration of all target machines, but at least it's a good start.
There's no need for the Winforms application to be installed. Just set Copy Local to true for your external referenced dlls. Build your project and copy all the files in /Bin/Release or /Bin/Debug (depending on project settings).
The only thing that has to be installed on the client's machine is the appropriate .Net Framework version.