I have a Windows Phone class library with a resources (.resx) file. I have a reference to the class library from an actual Windows Phone Application project. Everything works well when I reference the library project in the solution, but when I add a reference to the actual assembly (.dll) file then localization stops working and the Windows Phone Application just uses the default locale when navigating to the pages declared in the library assembly. Does anyone know why?
Found the solution. When you reference a Windows Phone library assembly (the .dll file itself, not its project within the same solution), you have to make sure that its resource folders are in the same directory as the assembly. That is, if your library is localized in Spanish for example, besides copying the .dll file from your bin folder, you must also copy the 'es' folder to the same directory.
Related
I am using JSON.Net to get my Console application to translate sentences with Google Translate. My code fully works fine with absolutely no errors when I run it in Visual Studio. But when I take the .exe out of the "[project_name]\bin\debug" folder and copy it to the desktop to run it returns the following exeception.
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified....
I noticed that in my "[project_name]\bin\debug" folder there is the .dll file that I am using, but not only this, I am also using a .dll that I referenced somewhere else.
When I drag this .dll file with the exe onto the desktop and run it, it works. How do I make it so that I don't need the .dll with the .exe on the desktop? Or is this something that is necessary? I am sure that I have referenced everything properly.
If your application makes use of a library then that library has to be there to make use of. There are basically two ways to make libraries available to .NET applications. The library needs to either be in the same folder as the application or it needs to be installed in the GAC (Global Assembly Cache). The GAC is a common location for libraries so that multiple applications can access them. Unless you intend to ensure that JSON.NET is installed in the GAC on every machine you plan to run your app on, you need to make sure that the library is deployed along with your app. This is how applications work. There is no magic solution.
I am using bPAC SDK provided by Brother for their label printer. I downloaded their SDK, took a bpac.dll file and put it inside my projects folder then referenced it. Everything works fine until I deploy my app to IIS server because, as it turns out, that bpac.dll is referencing another .dll in C:\Program Files\Common Files\Brother folder and IIS does not have required permissions to access that file. This is VERY strange, and strange is that the bpac.dll in my Visual Studio is marked as Interop, whatever it means. How to solve this? How impot all the .dlls to my project so it doesn't need to access files in system folders?
I am working for a company that registers a lot of COM DLLs in the System32 folder/SYSWOW64 folder. I recall a question some time ago where Hans Passent said that this is wrong as the folders specified are for Windows DLLs. I cannot find the post so I want to check that this is correct?
Also if I want to register a COM DLL or a TypeLibrary in a foreign folder then can I just use the following command (for COM):
regsvr32 app.dll
Finally I was reading about the CODEBASE flag of Regasm: http://www.vbforums.com/showthread.php?597928-RESOLVED-How-to-delete-a-VB6-Reference. Do you have to use this flag if you want to register a TypeLibrary (.TLB)? What happens if you .NET assembly uses a third party library that is not signed?
If you are talking about installing COM DLLs in the System folder, then you are correct. All applications, and their support libraries, should be installed under the Program Files folders, or the Common Program Files folders.
You are also correct that REGSVR32.EXE can be used to manually register DLLs and OCX. "Foreign folder" is not a Windows concept - you can register a component anywhere in the file system, including the Windows and Windows System folders. By the way, if you use an installer, then you shouldn't have to use REGSVR32.EXE.
However, TLB files cannot be registered with REGSVR32.EXE, because that application basically loads the DLL/OCX, and calls an exported function on the library, so effectively the library registers itself. Instead, you need another tool, e.g. REGTLIB.
You don't use /CODEBASE to register a raw type library, because REGASM is used for registering .NET DLLs as COM components, not TLB files.
Is there any way in VB.NET to DllImport a dll file from the resources?
I really don't want to add the dll with the executable path.
You can embed a DLL into an executable:
Jeffrey Richter: Excerpt #2 from CLR via C#, Third Edition
Many applications consist of an EXE file that depends on many DLL
files. When deploying this application, all the files must be
deployed. However, there is a technique that you can use to deploy
just a single EXE file. First, identify all the DLL files that your
EXE file depends on that do not ship as part of the Microsoft .NET
Framework itself. Then add these DLLs to your Visual Studio project.
For each DLL file you add, display its properties and change its
“Build Action” to “Embedded Resource.” This causes the C# compiler to
embed the DLL file(s) into your EXE file, and you can deploy this one
EXE file.
At runtime, the CLR won’t be able to find the dependent DLL
assemblies, which is a problem. To fix this, when your application
initializes, register a callback method with the AppDomain’s
ResolveAssembly event.
i added itextsharp.dll to my project. it is on my desktop. everything compiles and works fine. if i install my application on another computer it is looking for the same file itextsharp.dll on the users desktop.
how do i make it so that the DLL is built in to the project??
What's with the Desktop now?!
Bundle all your deployable assemblies in the same output folder as your application's main assembly.
While creating the Setup...I am assuming your using MS project setup..make sure all the deployables point to a common folder target.
I don't understand your fixation with Desktop...pls let me know if that is some sort of requirement.
The only thing that is usually deployed onto Desktop is the App's Shortcut.
Make sure that when you add the DLL to your project, you set 'Copy Local' to true. That way, the DLL will get copied to the 'bin' folder of your application rather than the original location of the DLL.