my issue is very similar to:
http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-vb/54944/VB-Net-project-throwing-errors-when-executing-Clean-Solution
Typical errors: Unable to load referenced library X
Type IWshRuntimeLibrary.WshShell is not defined.
Interface System.IDisposable is not implemented by this class.
Namespace of type specified in the Imports Z does not contain any public members or cannot be found. Make sure the imported element name does not use any aliases.
This must have to do with a VB.net project configuration. Currently there is a setting "Treat all warnings as errors". I would like to keep that setting, but also resolve these annoying "errors".
I've experienced a similar problem and fixed it by running the following command in the VS command line tool
devenv /resetskippkgs
I'ev had problems executing Clean's via MSBuild in VS2008 when projects were registered for COM interop.
The problem is that the "Clean" target auto-generated for a solution cleans projects in the same order in which they were built.
This causes problems for projects registered for COM when MSBuild attempts to load and then unregister the assembly from COM during a "Clean".The issue occurs if the assembly has a dependency on another project because the dependency will be deleted first and therefore loading the assembly will fail and MSBuild will be unable to unregister it.
A workaround is to change the solution .cache file (which contains the targets auto-generated by MSBuild during "Build") and reverse the order of the "Clean" target. I hacked-together a quick-fix custom build task to do this as a post-build step.
No idea if this was fixed in VS2010 or indeed if this matches your problem since you don't give many specifics in your question ;)
Related
I have a winforms app, which is deployed via click-once publishing.
Assuming my tests are correct, the only way to have this same app installed more than once in the same machine, is the each publish be made for a different Assembly Name.
My problem is that I am running the msbuild via jenkins, and, to accomplish the above, I would add /p:AssemblyName={whatever}, which will rename all assemblies generated by the build to this same {whatever} value. If the output of my build is 1 exe and 5 dlls, all 6 files will be named {whatever}.
Which in turn raises CS1704: An assembly with the same simple name {whatever} has already been imported.
Is the only way out of this to perform all csc.exe calls that msbuild generates, myself, and see if I can set different assembly names per project ?
Or are there other ways to solve this ?
The problem here is that every property passed to MSBuild as a command line argument is considered a global property and will override the property on all projects built in that invocation. The solution is to introduce an intermediate property that only the "main" project consumes.
Edit the app's csproj file to include this (in the place where AssemblyName is already defined - assuming here that WindowsFormsApp1 is the name of the application):
<AssemblyName>WindowsFormsApp1</AssemblyName>
<AssemblyName Condition="'$(OverrideAssemblyName)' != ''">$(OverrideAssemblyName)</AssemblyName>
you can then use the msbuild commands using /p:OverrideAssemblyName=AnotherName without creating conflicting assembly names on referenced libraries. The property is still defined globally, but only one project consumes it.
We are working on a validation script for Kofax Capture 9.0 / 10.0 in VB.NET 3.5.
We know how to create a script using the Admin Module, and how to get it operational.
The problem is that we need to reference a dll, located on a remote machine. (GAC is no option) This dll holds abstract classes we need in each validation script.
Even when putting the dlls locally (copy local), the Validation Module (index.exe) immediately throws the "cannot find reference" exception, even though the project compiled perfectly.
I guess the basic question comes down to: where do we put the dlls, in order for the Validation Module to find them?
The simple answer is to put the dll in the same folder as the application because this is one of the places which .NET will probe when trying to find it. The Validation module is run from the Capture bin directory which will be something like "C:\Program Files (x86)\Kofax\CaptureSS\ServLib\Bin\". This would need to be done on each client using Validation.
If you have a more complicated scenario, you could look implementing the AppDomain.AssemblyResolve Event and using Assembly.LoadFile to get the assembly from a custom location, but the using the bin path is less complicated.
If you end up having further trouble, you can troubleshoot by using the Assembly Binding Log Viewer (Fuslogvw.exe) which can tell you more details about why the assembly failed to load and where .NET tried to search for it. Assembly loading can fail for reasons other than just the path.
For more detail on how .NET loads assemblies, see the following:
How the Runtime Locates Assemblies
Locating the Assembly through Codebases or Probing
We found a solution: add all library files as "links" to the project. (Add --> Existing File --> small arrow next to "Add" --> Add as Link)
This ensures the files are compiled when you build the project. The Kofax Validation Module can now find the files, whereas when referencing the file, it could not. Why it could not, remains a mystery...
I'm trying to get TFS team-build to reliably build a WPF C# app. This app relies on a VB6Lib.dll which we maintain, this VB6Lib.dll itself relies on other C# libs that we also maintain.
I've set up a build definition to build (in order):
VbDependencies.sln (all libs in this have com interop set, thus the VB6 can find their TLBs)
buildVB6Lib.proj (an msbuild file which calls "VB6.exe /make /d" to make the VBLib.dll on the build server, as part of this script I've been copying the VB6Lib.dll output to C:\tmp)
MainApp.sln (in my workspace, I've added a reference to C:\tmp\VB6Lib.dll)
Does this sound ok
?
On my dev laptop I usually build the VB6, copy its output to \tmp and then regsvr32 it there before adding a reference to it in my C# solution. It's this step that I'm not convinced my build def is doing.
Also, is there a way to get more useful output from the VB6 build, currently I get "Compile Error in File 'xxx.bas' Can' find project of library", but not which actual library it can't find.
You are correct in that the critical point in your build process on the development system lies in registering the COM object. However, one does not in general want to register the COM object on the build server, as this can cause all kinds of versioning issues and silent failures when the wrong COM object is registered or the registration fails.
The proper way to accomplish this is to generate an interop assembly manually and reference that instead of the COM object. This is accomplished with the tlbimp utility, for instance:
tlbimp ..\Libraries\VBLib.dll /out:..\Libraries\Interop.VBLib.dll
Run that command on your development system, then remove the reference to VB6Lib.dll and add a reference to Interop.VBLib.dll. You can then add the tlbimp command as a prebuild event in the referencing project so that the interop assembly is always build from the correct version, and you will never again need to have your COM object registered on the build system.
I have a solution in VS 2008 that creates a DLL. I then use that DLL in another application. If I go in to the DLL projects property pages and change the following configuration for a DEBUG build then the built dll no long provides the desired functionality. If I change it back and rebuild the DLL, then the DLL does provide the correct functionality:
Property Pages => Configuration Properties => C/C++ => Code Generation => Runtime Library
If set to "Multi-threaded Debug DLL (/MDd)"
then everything works as it should. I get the correct functionality from the DLL
If set to "Multi-threaded DLL (/MD)" then the DLL does not function properly...no runtime errors or anything, it just doesn't work (The DLL is supposed to plot some lines on a map but does not in this mode).
So the question is, why does using the /MDd flag result in correction functionality of the underlying code, while /MD results in incorrect functionality?
A little background...somebody else developed the DLL in C++ and I am using this DLL in a VB.net application.
All DLL's/debug code generation must match across everything that uses them. There may be another referenced library or object or dll or some code in there that is built using the wrong options; or specific options for an individual element that override the global project options.
The only way of figuring it out is to meticulously check all of the options for each file, checking the included and referenced libraries (.lib and .dll) and object files. Check the linker options too.
The reason why it doesn't work is probably because the debug version adds extra guard blocks around memory to allow detection of errors.
I had similar problems. My application which "used" a 3rd party DLL crashed when its runtime library was set to "Multi-threaded DLL (/MD)", but worked when its runtime library was set to "Multi-threaded Debug DLL (/MDd)".
It has something to do with passing std::strings and std::lists across the DLL interface.
Our guess was the low level definition of these types was somehow different in the two runtime libraries.
We solved our related problems using this rule...
The DLL and the DLL user must be build using the exact same runtime library.
The main difference between the two options is in the libraries that your code will be linked at later. for the debug version for example this will include LIBCMTD.LIB and a few others. if your library is going to be built as debug the you should always link with MDd. failing to do so will result in lots of unresolved external linker errors at best. and sometimes the code compiles normally but crashes at runtime. if this happens in vb.net then a catch can easily hide the error. I guess you should make sure you build setting is correct. for more detailed information check this.
I have a project which uses C++/CLI to implement a GUI and some background processing to talk to a sensor. I've got that all working and a lot of the comms stuff which we use to communicate the the sensor sits in a .dll. The problem is that I'd like to combine the library into the main executable to avoid having to worry about distributing .dlls.
I've got a demo project which works fine using a .lib but when I try and switch the mani code body to produce a .lib instead of .dll I get the following error:
1>------ Build started: Project: MyTool, Configuration: Debug Win32 ------
1>Compiling...
1>stdafx.cpp
1>.\stdafx.cpp : fatal error C1113: #using failed on 'c:\projects\MyTool\debug\MyLib.lib'
A bit of googling suggests this happens when you've not got the MSIL switch applied, but it's definitely in there in the library project.
I have a mixture of managed and unmanaged code in both my demo project and the real thing so I'm really struggling to see what the problem is here.
Any suggestions would be very gratefully received!
I am guessing a bit, but I suspect the "MyTool" project has the "MyLib" project as one of its "references" ("Project" menu >> Properties >> Common Properties >> References).
When you change the type of the MyLib project to a LIB instead of a DLL, you need to remove "MyLib" from the project references. You then update the project dependencies of the solution ("Project" menu >> "Project Dependencies...") so that MyTool depends on MyLib.
If you are linking to a mixed mode (managed/native) DLL you may get this error. Which you shouldn't if the project uses CLR even if one of the source files doesn't. But anyway, if that is the case, then try removing the reference from Project|Properties|Common Properties|References and then re-adding it.
I also ran into this. The reason it was failing was because I was compiling my native/managed C++ DLL to target .NET 4.0. And the DLL I was #using was a .NET 2.0 DLL. As such it was failing, even though the paths and file names lined up perfectly. In this case the error message was absolutely of no help at all.
I solve it by updating the independent DLL to .NET 4.0. So that both assemblies were using the same .NET framework.