I'm using tlbimp to generate a .Net interop of a COM assembly. This COM assembly has a product version and file version like 7.X.X.X but when I'm using TlbImp, my interop has then a version like 1.Y.0.0. I'm aware I can change this version when I'm using TLBImp via parameters of the executed command lines but I'm wondering where this version comes from.
Can I access a manifest of this COM assembly?
Why I cannot see this version on the property of the file in the explorer?
I have different version of this assembly and I see the version generated always different but I'm failing to find where this version come from.
Thanks
I had a hunch that it was the version of the typelib. I took a test project that had a typelib of version 1.0 and ran tlbimp on it, and it produced an import assembly with file version of 1.0. I then changed the version of the typelib to 1.19, recompiled, and reran tlbimp. The file version of the new import assembly was 1.19 (well, 1.19.0.0).
Using OleView you can load the typelib of the EXE/DLL your using for tlbimp. Check the version of the typelibrary. Compare it to the file version of your import assembly. I bet they match.
Makes sense they'd want the version numbers to match.
Related
I just upgraded my TFS source to use DevExpress 15.2.5. However, now I get a bunch of warnings in the output such as
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3274: The primary reference "C:\Users\User1\Source\Release\V6.1\CommonBin\Release\WebControls.dll" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v3.5".
and
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3275: The primary reference "C:\Users\User1\Source\Release\V6.1\CommonBin\Release\WebControls.dll" could not be resolved because it has an indirect dependency on the assembly "DevExpress.Data.v15.2, Version=15.2.5.0, Culture=neutral, PublicKeyToken=7ea533hgx2169hs3" which was built against the ".NETFramework,Version=v4.0,Profile=Client" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v3.5".
along with about 30 other similar warnings.
It's obvious that something is out of sync with my assemblies because they are referencing the wrong versions. So I looked at my TFS project .csproj file. The version of DevExpress and .NET framework that are being referenced in there are correct.
I then went to the Microsoft.Common.targets file and opened in Notepad. I noticed that file is referencing the old version of everything. How do I get this in sync with my TFS assemblies?
It looks like you need to change your project to use the .NET framework version 4.5 on the project properties page:
Word of warning this may result in more warnings or errors depending on the .NET APIs you use.
I was setting up number of projects to build NuGet packages and push onto NuGet server, so it could be later used by Octopus Deploy.
All was fine until I needed to apply the same process to legacy projects. The error was:
error MSB4062: The "OctoPack.Tasks.CreateOctoPackPackage" task could not be loaded from the assembly ...\OctoPack.Tasks.dll. Could not load file or assembly 'file:///...\OctoPack.Tasks.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. Confirm that the declaration is correct, and that the assembly and all its dependencies are available.
Now I understand that OctoPack was not built for .Net 2.0, but just wonder if anyone hit/solved that problem.
Are you able to change the build target of the application from 2.0 to something more recent? If so, I would upgrade my app, rather than look for a downgraded version of Octopack.
Alternatively, you can use NuGet.exe to create packages rather than using OctoPack. I actually prefer OctoPack, but NuGet.exe wouldn't care about your .NET version.
I ended up amending the Octopack code to work with .Net 2.0 and MSBuild 2, which is successfully applied to all our .Net 2.0 and 3.5 applications being packaged on the CruiseControl server.
If someone is in a similar situation here is the amended code (forked from the original Octopack)
System.Data.SQLite (SDS) is apparently the most popular way to use SQLite from a .Net application.
I was wondering if
SDS requires shipping the SQLite DLL in addition, or if SDS includes
the SQLite source code, and
SDS can be statically compiled into a
VB.Net application of it can only be shipped as a DLL?
Thank you.
To expand on my comment, SDS is a .net wrapper for unmanaged code, so you will need to ship your release code with a copy of the DLL.
As Steve mentions, there are 32 and 64bit versions of the DLL, and as i discovered after much frustration, you must have the corresponding visual c++ runtime installed on the target machine, so if you deploy the 32bit version onto a 64bit machine, it will need the 32bit c++ runtime environment installed.
An alternative that i am currently looking into but havent had time to test is csharpe-sqlite, a pure .net implementation:
http://code.google.com/p/csharp-sqlite/
Coded in c# as the name suggests, but of course usable in any .net language including vb.net
Actually it's quite easy to compile System.Data.SQLite.dll to the does not require C++ runtime. For example if you download source code and follow the build procedures you'll find statically linked (no C/C++ runtime required) copy of System.Data.SQLite.dll in the following path:
<your-src-root>\bin\<2008 or 2010>\<Win32 or x64>\ReleaseStatic
For example if your source is in C:\Work\sqlite-netFx-source-1.0.80.0 then statically linked binary for Win32 and .NET 3.5 (VS 2008) will be located in:
C:\Work\sqlite-netFx-source-1.0.80.0\bin\2008\Win32\ReleaseStatic
Furthermore since System.Data.SQLite.dll is a mixed-mode assembly consisting of a managed .netmodule and native .obj file linked together using link.exe, it is possible to build your app as a .netmodule as well and link it together with SQLite into a single mixed mode assembly.
The resulting assembly will still be either Win32 or x64, however since almost all x64 machines will have no problem running Win32 code you can just settle on Win32 as long as:
Your app is an .exe or a .dll the is always loaded into a Win32 process, and
You don't use any of x64 specific advantages such as larger address space or using unmanaged code available only in x64
I installed the VS2010 and .NET 4.0, then I compiled an assembly and ran the gacutil using the exe available on
%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
The output of the executable said the assembly was sucessfully installed on Global Assembly Cache. However, when I go to %WINDIR%\assembly folder I cannot find the assembly I installed using the .NET Framework 4.0 gacutil.
I've seen some posts saying the .NET Framework 4.0 has a separated GAC, but what I haven't found was where it is located.
May someone to help me to check where can I see the Global Assembly Cache of .NET Framework, as it used to work on previous version (%WINDIR%\assembly)?
Yes, there are two distinct GACs as from .NET 4.0
See here: .NET 4.0 has a new GAC, why?
As stated below, the new physical location is %windir%\Microsoft.NET\assembly\ (you can interogate it using the dir command at a command prompt if you're interested).
It's worth noting that applications running up to the 2.0 CLR will not even be able to see assemblies in the new GAC.
Try:
%windir%\Microsoft.NET\assembly\
Due to Common Language Runtime (CLR) changes, the contents of the Global Assembly Cache (GAC) is split between two directories:
%WINDIR%\assembly\
%WINDIR%\Microsoft.NET\assembly\
If you run the command gacutil -l from the directory of your project's .csproj file, you will get a printout of the contents of the GAC (the contents of both directories).
Please excuse the large amount of background info, but this is a fairly specific question.
I have a Visual Studio 2005 project that creates a .dll file. This project depends on a .dll from another company, "BigCorp", which gets installed with BigCorp's software.
Ideally the dll I create should be usable with any (backwards compatible) version of BigCorp's dll. That is, if I link against version 4.3.2.100 my program should still work if the user upgrades BigCorp's app so that the .dll is version 4.3.3.20.
This is straightforward enough in VS2005, by looking at the project's References, selecting the .dll and making sure the "Specific Version" property is false.
Now for my actual question: Is it possible to specify a base version of the .dll that is older than the one installed on the machine that is building the project? Continuing my previous example, my build machine has version 4.3.3.20 installed, but I want the .dll it generates to be compatible with installations that haven't upgraded, and only have version 4.3.2.100 installed.
It seems that VS resolves the path to the .dll and detects the runtime version based on the file it finds. Trying to override it by specifying the version number directly in the .vbproj or .csproj, i.e.,
<Reference Include="BigCorp.Program.Component, Version=4.3.2.100, Culture=neutral, PublicKeyToken=abc123def456654fed321cba, processorArchitecture=MSIL">
has no effect. Trying to register my assembly on a computer that has the older version fails with the good old "Could not load file or assembly" error because it tries to find the newer version of BigCorp's .dll.
Is what I want to do even possible?
You can do this by referencing the older DLL directly from the project, so copy the .dll file to your project, then reference it from there.
I do this all the time with my various development projects. Typically I'll put a "References" folder inside my project to hold referenced DLL's