I haven't done COM in over 10 years so I was wondering:
When I utilize a 3rd party COM based SDK by importing its TLB file -- is it their responsibility to release a version of TLB for each version of visual studio I use their SDK with? or is TLB a "flat" binary file that fits all versions of visual studio?
The type library format is standardized and independent of any tool that reads it, including Visual Studio. Tools use ITypeLib and ITypeInfo to read one, implemented by Oleaut32.dll
Related
The reason I ask is I want a small installation size and I only use the product for writing code for school work. I will not need 3rd party software, web capability, or integration with other software and applications.
In a comment now you requested for "command line to run the web installer in a certain predefined way say only download and install visual studio core editor and.net components". BTW, the recommendation including installing .NET components was a part of my original answer- now I splitted the answers, one for minimal install and this one for what you requested secondly, including .NET Visual Studio components:
The command line to install core and .net minimal is:
vs_xxxx.exe --layout %CD%\vs2017offline --lang en-US --add Microsoft.VisualStudio.Workload.ManagedDesktop
(set your individual downloaded .exe name for 'vs_xxxx.exe', my downloaded name was for example 'vs_enterprise__873301792.1489161815.exe')
The new installer for Visual Studio gives you a lot of flexibility about which components to install. By default, you'll have no additional features selected. VS will only install what it calls the Visual Studio core editor, which is described as:
The Visual Studio core shell experience including syntax-aware code editing, source code control and work item management.
With this, you'll get support for TextMate language grammars (you can install any you want), but you won't have the overhead of installing any language services or project types. So far, VS is a glorified editor; this minimal install will take 600MB. If you're looking for something smaller, you should probably consider Visual Studio Code instead.
Workloads
The first tab of the new VS installer is the Workloads section. This gives you some pre-packaged feature groups targeted at specific development platforms. There are separate categories of workloads (Windows, Web, Gaming, and Other) and taking the Windows category for example, there are 3 different workloads available: UWP, .NET Desktop (like WinForms and WPF), and C++ Desktop development.
Each workload has required and optional features. Some of the optional features will be selected by default as they are "recommended". You can slim down by unselecting these.
If the workloads are too heavy-handed for you, you can use...
Individual components
On this tab, you can piece together any single components you want. If a workload seems too large, you can see what components it would install, then go to this tab and pick the smaller set you would like.
Note that some components do have dependencies (sometimes numerous), and the installer will show you all of the dependent packages added. If you try to remove them, it will notify you of dependent components that will also be removed.
You have the following alternatives:
1.
Minimal Visual Studio: Start the standard Visual Studio web installer, and select nothing, then you get the minimal installation for only the development environment (IDE), especially editor.
2.
If this is too big for you, you can use something similar to Visual Studio, for example, you can Visual Studio Code editor or you can use SharpDevelop as an alternative to Visual Studio. Open Source and smaller footprint.
You can work with every editor on the commandline using "csc.exe myhomework.cs" (CSharp compiler).
3.
The solution with smallest footprint (without Visual Studio):
Just use the editor you are used to, even notepad is possible: Depending on your .NET version and Windows directory, the compiler can be found for example here:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe
or
C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe
The 64 bit versions of those you get in the mirrored folders "Framework64" instead of "Framework"..
Normally you would like to download the whole .NET SDK (developer pack) additionally, but for a single homework, csc.exe might be enough.
Here is the developer pack for .NET 6.2 framework (Visual Studio uses that as kind of a kernel too).
https://www.microsoft.com/en-us/download/details.aspx?id=53321
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'm writing a simple C++ application in Visual Studio. It also has a setup project.
It works well on my development machine, but when I'm installing this application on user's machine it requires Visual C++ Redistributable Package. I'm wondering why does my application require C++ Redistributable? Standard C++ runtime library is shipped with Windows, isn't it?
The only version of the C runtime library which is shipped by Microsoft with most of 32 bit Windows versions is msvcrt.dll. This library provides a typical set of library functions required by C and C++ programs. These include string manipulation, memory allocation, C-style input/output calls, etc.
Visual Studio 6.0's compiler links against this library, so if you are developing in VS 6.0 you shouldn't encounter any problems on most users' machines.
However, if you are developing in VS 2005, VS 2008, VS 2010, VS 2012, VS 2013 or VS 2015, you have to distribute additional C runtime libraries along with your application. This is because their compilers link against msvcrt80.dll, msvcrt90.dll, msvcrt100.dll, msvcrt110.dll, msvcrt120.dll and msvcrt140.dll respectively, which are not shipped with Windows.
Solutions:
Possible solution is to link statically with runtime library, but it may cause a lot of problems in case you have both .exe and .dll in your application. Don't do that.
To be more specific, I'll allow myself to quote a part of this answer:
Using /MT is risky if you create DLLs as well as an EXE. You'll end up
with multiple copies of the CRT in your program. This was especially a
problem with earlier versions of VS where each CRT would get its own
heap, not so much with VS2012. But you can still have ugly runtime
problems when you have more than one "errno" variable for example.
Using /MD is highly recommended to avoid such lossage.
Another possible solution is to require an appropriate Microsoft Visual C++ Redistributable package to be installed on the user's machine.
It may be done by specifying this requirement in prerequisites property in your setup project.
Also, you can distribute the runtime dll by including in your setup project the appropriate "merge module". In this case don't forget to add the appropriate "policy merge module" to avoid errors caused by incorrect runtime version.
Finally, you can just put required DLLs in the same folder in which your application is installed.
Further reading:
"Redistributing Visual C++ Files" - Official MSDN documentation
Even though some comments said that «link statically with runtime library, but it may cause a lot of problems when you have both .exe and .dll in your application.» this is NOT TRUE. First we DON'T statically link DLLs! We statically link OBJs and LIBs. LIBs are static libraries; DLLs are dynamic libraries, and you may choose to use LIBs (static) or DLLs (dynamic). It's entirely up to you to choose. The ONLY drawback (for the DLL fans) is that if you want to update one library, you need to compile and link again. I personally deploy ALL my software static linked and because of that I earn the bonus of don't even need installers. The software I develop is 100% portable (a feature that in the pre-installer era was general procedure), and the final user is free to simple COPY from one folder to another or even from the hard drive to flash drive (or vice-versa). The error message «DLL not found.» simply doesn't exist ... NEVER.
Some folks think of statically linking as toy software: WRONG! I can write a full featured application that connects to a DBMS (Oracle, SQL Server, ...) or any other kind of application.
The requirements listed in the 3ds Max SDK state that plug-ins for 3ds Max 2011 must be built with Visual C++ 9.0 (Visual Studio 2008).
If I create a DLL with a different version of Visual C++, won't the binary be identical? Is this simply a matter of choosing the right compiler settings?
What problems will I run into if I try to build a plug-in using Visual C++ 2010 (Visual Studio 2010)?
I don't know specifically for 3ds Max, but the usual reason is the C Runtime library. If the host application uses the DLL version of the CRT, then plugins will also need to use the same version.
Otherwise, imagine the case where your plugin creates some memory using malloc(), and passes it to the host application, which uses it and then calls free(). If your plugin and the host application are using different CRTs, the host's call to free() will fail or crash because it wasn't the host's CRT that malloc()ed that block of memory.
The binary won't be identical but the binary interfaces should be, which is what you need.
The reason you can't use VS2010 is because it is not yet production quality. They think you should wait for VS2010 SP1 at a minimum.
You think they are just being obstinate and stubborn, eh? Ruining all your fun. They have reasons. Good ones.
Because of bugs like this:
https://connect.microsoft.com/VisualStudio/feedback/details/565959
I use both visual studio 2008 and 2010 for plugin development.
Only difference I've seen is that the user need the vs c++ runtime version for 2010\2008.
But there might be pitfalls - but I have not encountered any problems with it yet.
C++ doesn't have a standardised binary interface. The compiler "mangles" each symbol name (i.e. each function or static data) to include information about namespaces and signature, so that namespaces, argument overloading, &c. can work. Each compiler is free to decide how to do this. Different MSVS compiler versions do name mangling in different ways, so in general you can't link a C++ library compiled with 2005 and a library compiled with 2008 together: this includes loading a 2008 DLL from a 2005 executable (for example). You can do this if the interface between the libraries is C, as long as the relevant functions are marked with extern "C" to prevent name mangling. And in practice the differences are not always that great: for example, I never had trouble using VS2005 SP1 to compile a library for 3ds Max 9, which supposedly requires VS2005 with no service pack.
Microsoft is trying to fix this incompatibility, so in VS2010 they introduced an option, so VS2010 can produce binaries compatible with VS2005 programs or VS2008 programs (maybe some earlier versions too, I forget). If you have to create a plugin to work with multiple 3ds Max versions, and you don't get caught out by any VS2010 bugs, this is probably a good option. Also, the Intel C++ compiler has a mode where it produces binaries that are compatible with an MSVS version of your choice, which might be a better option for you if it's for hobby use or you can afford the slightly expensive price tag. (They achieve this by copying the way MSVS does name mangling.)
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.