I have a warning when I build my Windows 8 App project in VS2012:
No implementation file was provided for the .winmd file 'C:\Users\luke\LApp\LApp\bin\x86\Debug\Bing.Maps.winmd'. To generate registration information in the app manifest, specify the 'Implementation' metadata on the .winmd reference item in the project file.
I don't really know what other information to provide. I've Googled and it doesn't provide any relevant results. It gives a link to this: http://msdn.microsoft.com/en-us/library/hh708954.aspx but I'm not sure it is the correct thing. I'm pretty sure I have the correct references:
It is a C# project. I used NuGet to add the Bing Maps SDK and it works in my app - I can drag on a map interface and use it in the app. This is just a warning that shows up when building and I have no idea how to get rid of it.
Any help appreciated, thanks.
Is your project a c# project?
Usually WinRT components implemented using .NET are just .winmd files. Both interface and implementation are contained within the .winmd file. Whereas native components (those written in C++) will have separate .winmd and .dll files for interface and implementation respectively.
It would be helpful if you could provide more details about your app project and the repro steps.
Related
Getting error Barcode Engine assembly not found
when trying to implement example "BarcodeReader_ReadBarcodeExample4()" in following link
https://www.leadtools.com/help/leadtools/v19/dh/ba/leadtools.barcode~leadtools.barcode.barcodereader~readbarcode(rasterimage,logicalrectangle,barcodesymbology[],barcodereadoptions[]).html
Any idea?
The most likely cause is that you are missing a reference DLL that needs to be present alongside your program's executable in order for the demo application to function correctly.
The example you mentioned deals with UPC barcode symbologies. This means you will at least need Leadtools.Barcode.OneD.dll in addition to the assemblies you already included.
Also, if you try to load or save images, you will need to add references to file format codecs. For example, if you're going to work with PNG files, you must add Leadtools.codecs.png.dll.
You can refer to the following help page in our documentation to see which assemblies you would specifically need:
https://www.leadtools.com/help/leadtools/v19m/dh/to/filestobeincludedwithyourapplication.html
Note that if you build one of the demo applications that ship with the toolkit, it normally outputs the EXE to the Bin folder where all the assemblies are located. This helps you avoid reference problems during development, but when you deploy your program, you must prepare a list of files you need and include them in your deployment.
If you are still facing problems getting this code to work, feel free to contact LEADTOOLS support by email (support#leadtools.com) or by Live Chat through our website.
I have developed a lot of class library projects in VS 2012 to be used in Windows Forms and Web forms applications.
The question is simple. Do I need to deploy the DLL file itself together with the XML file that is created?
For example, the class library project is called DataWare. Upon building, I got 5 files in Release folder (this project reference Entity Framework):
DataWare.dll
DataWare.pdb
DataWare.dll.config
EntityFramework.dll
EntityFramework.xml
I know that ".pdb" file contains debugging information, so there is no need to deploy. The ".config" file is not taken into account. Instead the App.config or Web.config are.
Regarding this, I think I have to deploy just DataWare.dll and EntityFramework.dll.
However, the main doubt is if I need to deploy EntityFramework.xml as well.
Regards
Jaime
The XML file contains the doc comments for the public types & members in the assembly.
You only need it if you want Visual Studio to show documentation in IntelliSense.
If you're deploying a consumer-facing app (as opposed to a developer-facing reusable library), you do not need it.
No, in most cases you do not need it. If there is an external DLL that needs to be copied local and referenced using the config, then you might need to, but that is somewhat rare.
I have a c++/CLI library that is in turn calling a c# library. That is fine, it is linking implicitly and all is good with the world. But for various reasons the libraries are not getting quite the prefect treatment by our automated build process, and the libraries are not finding each other unless we move the libraries to locations that we would rather not have them in, and would rather not fold into our build process.
It is suggested to me that we/I could write a post-build event that uses XCOPY. but lets say we don't want to do that.
Another suggestion is to explicitly load the dll. Windows says that to link explicitly "Applications must make a function call to explicitly load the DLL at run time." The problem is that Microsoft's example is not enough for my small mind to understand how to proceed with this idea. Worse, the only example I could find is out of date. Perhaps I am not using the right search terms but I am having difficulty finding more about it with google.
How do we explicitly Link a c++/Cli Library to a C# .dll?
----edit
OK, How do we explicitly Link a C++/CLI code, which exports a library using __declspec(), to a C# .dll.
There is no such thing as a "C++/CLI library", only assemblies are supported. There is no explicit or implicit linking, binding always happens at runtime. Assemblies are found at runtime by the CLR, the rules it uses to locate them are described in detail in the MSDN library.
Copying all dependencies into the same directory as the EXE is the sane way to go about it while you are developing the code. Well supported by build system, the C# and C++ rules are however different. C++ projects build to the solution's Debug directory, C# projects build to the EXE project's bin\Debug directory. So yes, altering a C++ project's Output Directory setting or copying files with a post build event is usually required to get everything together.
I have a C# library that was developed in-house to provide an interface to our legacy software. Over the time requirements grew and now here I am to add COM visibility to this interface library so that it can be accessed from something like VBA in the MS Office applications.
Update 3: Added bit more details in the 'Existing Design' text.
Existing Design:
Let's call my interface library as Interface.dll. It's a facade pattern which includes some backend /dlls, which are dependencies for this Interface.dll. Let's call them as:
MyTypeLib.dll, MyHelper1.dll, MyHelper2.dll and few more helpers. Every .dll mentioned above is a separate library project in my solution.
My approach was:
Develop a new library that has a COM visible class. I did something like:
Update 1,2: Added my interface sample code
[Guid("CE3750B7-DE31-4635-A69C-110B1271B363")]
public interface ICOMVisibleClass
{
...
...
}
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.AutoDual)]
[Guid("A023101A-D9B3-4A24-AAE4-B3CFEDA04BAF")]
public class MyCOMVisibleClass : ICOMVisibleClass
{
...
...
}
and selectively call methods from Interface.dll, making these selected methods COM visible. Let's say above class produces MyCOMVisibleClassLib.dll. I used RegAsm.exe to register this library and to produce MyCOMVisibleClassLib.tlb file.
To test this implementation, I decided to use MS Excel 2010. I opened VBA editor and added a reference to MyCOMVisibleClassLib.tlb. In the code, I can now see all the methods in MyCOMVisibleClass so it seems to be working until.....
I ran this code and got "Run-time Error -2146233088 (80131500). Unable to find MyTypeLib.dll"
I used Assembly Binding Log Viewer to see more details of this error and found that MS Excel was looking for this (MyTypeLib.dll) everywhere except where actually this file is. If I copy this file into Excel installation folder under Program Files, Excel would compain about next dependency - MyHelper1.dll and so on. After I copied all the dlls to Excel install folder all was good. But this is not the solution I am looking for.
Questions:
Is my approach correct to open up few methods to COM?
I think that MyCOMVisibleClassLib.dll is the only one that needs to be registered. Am I right in thinking so?
How do I make Excel to find all my dependencies (MyTypeLib.dll, MyHelper1.dll, MyHelper2.dll ) without having to copy them in MS Excel install folder?
I also think that I am missing something basic that I should have known before I start this but can't seem to figure it out.
Any help is very much appreciated. Thanks in advance.
I finally got around the problem. Here is what I did:
Strong named and signed all the assemblies including the one that needs to be registered.
Used RegAsm to generate .tlb file. There is a catch here - If you are deploying your solution for 64 bit version like in my case - I was going to use this interface for 64-bit MS Excel - you MUST use 64 bit version of RegAsm found under "C:\Windows\Microsoft.NET\Framework64" to create .tlb file. For 32 bit solution use RegAsm from "C:\Windows\Microsoft.NET\Framework" folder.
Created a setup project in VS2010 to include output from MyCOMVisibleClassLib project, all its dependencies and MyCOMVisibleClassLib.tlb file
You can install all these files in GAC except .tlb file. So I chose to install in the application folder (under Program Files)
After running the setup all went well and Excel seem to locate the files correctly now.
Can anyone tell clearly about the usage of header files and namespaces in C#?
Because in C++ I was using ******.h files to read library functions. And when I saw some sample programs in C# they were missing, Can anyone tell me why?
I'm using C# to develop a custom tool for a CAD application. Whenever I use the appropriate function to open the file (CAD file), the compiler is giving me an error stating that the function names which I supply are not available in the context. Here what does meant by context?
When I opened the help file of that CAD application the function which is responsible for opening the file has bee mentioned under a header file called uf_part.h. But there is an namespace called NXOpen.
I used the namespace as using NXOpen in Visual Basic, isn't that enough? DO I need to supply that header file as well? If so, how?
C# is more "programmer friendly". When dealing with files of the same project, instead of manually specifying "header file" every time, it will go and look in all the project files for a match according to the namespace.
To understand this, do the following steps:
Start new project in Visual Studio. (No matter what type, WinForms or Console)
Right click the project and add new class.
In your main class note you can see the new class you just added, without adding any header.
How this is done? Simply by having the same namespace to both classes. The .NET engine is smart enough to link all those classes together.
Now, when it comes to external code meaning code sitting in a different DLL file the trick is to add reference to that DLL (in Studio --> Right click project --> Add reference --> Browse) then you need to specify you are going to use that DLL by adding a using statement on top:
using ExternalDllName.ExternalNamespace;
That's about it. Unlike C++ you don't need to have .h file as .NET will automatically search the referenced DLL files for a match.
There's no such thing as header file in .net, because all needed metadata is contained in referenced assembly itself.
Have you referenced needed assembly in you project?
Also please mind that there's no such thing as "function" in C#, only class methods (which means that you have to specify object or static class in you call).
Also: General Structure of a C# Program
Compilers for modern languages, such as C# or Java store within compiled files information on the classes and methods they contain, and this information can be used to check the correctness of calls made from one source file to another or to library classes.
When C was invented disk space, memory and CPU power were precious resources and this approach would not have been possible. Header files were introduced to allow the compiler to check that different source files conformed to the same interface. When C++ was invented the approach described above could have been possible, but I guess that it was chosen to stick to the C one for compatibility reasons.