I have a C# project in Visual Studio 2005 that is referencing a few COM libraries. When I build it errors like this are thrown:
Referenced assembly 'assemblyName' does not have a strong name.
Now, I used to reference COM assemblies in Visual Studio 2003, and it would automatically sign the Interop wrappers. All I had to do was set the setting 'Wrapper Assembly Key File'.
I tried finding a similar setting in Visual Studio 2005, but I couldn't find any. So I was wondering if there's any equivalent way of strong naming COM Interops in Visual Studio 2005 and getting rid of the above error.
It looks like it was already answered in "Where is the Wrapper Assembly Key File setting in VS 2008?" question.
Instead of using Visual Studio you could use Tlbimp.exe and
Aximp.exe to generate the Interops. Tlbimp.exe has options for signing.
I have used them to be generate an Interop file for each different version of the same COM component in my application. The COM components are vendor supplied COM components used for accessing data points in mass spectrometry files and the COM interface change from time to time as new versions of the vendor software is released. The application can then decide at runtime which Interop to use in order to match what version is installed on the computer where the application is installed.
The BAT file I use for generating the Interops is online.
Related
In visual studio we reference an external dll in our project with the option copy local to true. The problem is that the client may have a different version of that dll in their system and in that case our app has to use their dll.
Is there a way in our visual studio project to specify the order in which it have to search for the dll at runtime?
Example:
Search in C:\Program Files\RuntimeX\runtime.dll
Search in current .exe folder
Clarification:
In this article they refer to the task i want to do, but i cannot find the technical part of how you configure the binding priority order.
How are references located in .NET?
Part: Runtime Reference Resolution (aka binding)
Is this dll a part of visual studio tools for office or Microsoft Office Word s/w?
PIAs are just intermidiate files that are used in transferring/marshalling calls between mananged/unmanaged boundaries. For example, they are used to convert managed types to unmanaged ones. You can generate them on your own without VS involved. Under the hood, VS uses the same tools to generate them when you add an unmanaged references (COM).
You can read more about PIAs in the Office Primary Interop Assemblies section in MSDN.
I work on WinApp in Visual Studio 2010 (With C# Language)
I want to add one dll (not system dll) to Reference.
but when I open Add Reference Window And Browse dll see under error message:
Could not load file or assembly 'W2D_D2.dll' or one of its
dependencies. The module was expected to contain an assembly manifest.
this file may not be a managed assembly.
I even change the Target Platform from ".net framework 4 client profile" to ".net framework 4" but not difference.
How Can Add This dll To My Project?
Looks like this DLL is not a managed assembly. You can check this very quickly by trying to open it with ILSpy or Reflector.
If this is the case, you'll have to pinvoke or use com to use this dll.
I'm using the Visual Studio Setup project. If I go to the properties of the Setup project, it lets me choose which pre-reqs are required, at which point I choose the C++ Redistributable.
On some systems, this works fine - but recently my users are reporting that the install failed because "A newer version of Microsoft Visual C++ 2010 Redistributable has been detected on the machine."
What's the proper way to do this? Is Visual Studio's detection fouled up somehow and unable to detect C++?
Yuck, this is ugly. I was wondering what would happen after Microsoft gave up on the side-by-side install of the runtime DLLs for VS2010. Seems clear, the interwebs are full of this installer error. The biggest victim seems to be Microsoft itself with Streets and Maps failing to install.
I'm not aware of any security patches for it so I have to guess that you haven't updated to SP1 yet. And your customers use a product of a vendor that did. This is a battle that you're always going to lose some day. Do consider taking advantage of the app-local deployment for the DLLs, copying them in the same directory as your main EXE. Simply copy them from the vc/redist directory before putting the setup package together, no need to tick the prerequisite. You'll need:
msvcr100.dll and msvcp100.dll for the regular CRT
atl100.dll if you use ATL
mfc100.dll, mfc100u.dll, mfcm100.dll, mfc100u.dll if you use MFC (u = Unicode, m = managed)
mfc100xxx.dll where xxx is the 3 letter language code if you use MFC on a non-English machine
vcomp100.dll if you use OpenMP in your code.
Only disadvantage is that they won't get updated if there's a security patch. That could be an advantage too, depending on what color glasses you wear. If you're uncomfortable about it then keeping the machine that creates the setup package updated, including enabling Windows Update, is an important requirement.
The default Visual C++ 2010 Redistributable uses a Product Code for detection. So Visual C++ 2010 SP1 Redistributable is not detected as installed. This is why the package tries to install it and fails.
A good solution is to create your own custom prerequisite which uses a better detection criteria. Here is an article which may help you:
http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx
Visual Studio setup projects do not support custom prerequisite creation. However, it can be done by manually generating the required manifests.
You can find the manifests structure here: http://msdn.microsoft.com/en-us/library/ms229223(VS.80).aspx
These manifests can be generated automatically with the Bootstrapper Manifest Generator tool.
After generating the package manifests, you can add all these files (including the package) in a separate folder in the Visual Studio prerequisites folder, for example:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\
This way Visual Studio will show the prerequisite in your setup project properties page.
I have installed the 2007 PIA and repaired my Office 2007 installation.
Still, when I add a reference to the Office 12 Object Library in VS2005, I only see Office.Core and cannot add an 'imports' statement for Office.Interop
I have checked that Windows\assembly\gac\ has got the interop dlls.
With the PIAs installed, you have to add a reference to the corresponding COM library - instead of generating an automatic interop, the PIA will be used instead.
To quote Microsoft's documentation
For Microsoft Office applications that do not have projects in Visual Studio Tools for Office, you must add a reference to the appropriate application or component to your project manually. Adding a reference to the component references the primary interop assembly, if the assembly is installed in the global assembly cache. Office applications and components are accessible from the COM tab of the Add Reference dialog box.
Add a browse reference. You have to ship the PIA dll to get any benefit out of it anyway.