I have a set of unit tests that use Shims from MS Fakes to test some static methods. I am currently using 4 fake assemblies, all of which reside in a single assembly. This fakes assembly is then referenced by the unit test assemblies that need it.
When we run locally in VS2013, all is fine, but when we try to do a build in Visual Studio Online, it fails with the following type of error:
MockLogManager.cs (25): 'ShimJsonLogger' does not contain a definition for 'LogGet'
Any ideas why it seems to be building the ShimJsonLogger but not giving it all of the properties we need?
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.
I'm creating a class library with integration tests. I'm using combination of FsCheck and xUnit here. Tests are supposed to run queries on the database to verify an output. I'm using FSharp.Data.TypeProviders with System.Data.Linq (so Linq2Sql type provider) to access the database - type provider is defined inside test class library itself.
However when I'm trying to build a project, I'm getting a Static linking may not use assembly that targets different profile. error. Class library, where tests are located is targeting .NET Framework 4.5 (FSharp runtime 4.4.0). I've also set binding redirects for FSharp.Core assembly, however this doesn't change anything.
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 four assemblies (plus the .NET 3.5 system.core) that I am installing as unsafe CLR assemblies in a SQL Server 2005 database. Installing the assemblies in the correct order (based on their dependencies) works fine, and I am able to use the CLR functions I need. If possible, I would like to use ILMerge on the four assemblies so that I can install just one DLL. Only one assembly is directly referenced from the SQL side anyway; the others are dependencies. It happens that one of those four assemblies is an XmlSerializer assembly generated with sgen, which is required because the SQL Server CLR will not allow the serializer to be created at runtime.
In the following discussion, the assemblies are called:
ClrIntegration.dll (this is a CLR library in Visual Studio 2008 and is the only library actually referenced from SQL)
CalcLibrary.dll (this is just a .NET 3.5 library that ClrIntegration.dll uses)
CalcLibrary.Schema.dll (this is a .NET 3.5 library whose code is generated entirely by running xsd.exe on two .xsd files -- CalcLibrary.dll uses this library)
CalcLibrary.Schema.XmlSerializers.dll (this is generated by running sgen on CalcLibrary.Schema and is used automatically by an XmlSerializer in CalcLibrary.dll)
To my knowledge, it is not possible to reference the version of CalcLibrary.dll that is in my VS2008 solution directly from the ClrIntegration project. Instead, I have to install CalcLibrary.dll on a running SQL Server 2005 instance and add it as a database reference to the ClrIntegration project. This is a nuisance, but I've made it work so far.
The basic command line I am using as a post-build event in the ClrIntegration project is:
"c:\Program Files (x86)\Microsoft\ILMerge\ILMerge.exe" /targetplatform:v2 /out:ClrMergedAssembly.dll \
"$(TargetDir)ClrIntegration.dll" \
"$(SolutionDir)Source\CalcLibrary\$(OutDir)CalcLibrary.dll" \
"$(SolutionDir)Source\CalcLibrary.Schema\$(OutDir)CalcLibrary.Schema.dll" \
"$(SolutionDir)Source\CalcLibrary.Schema\$(OutDir)CalcLibrary.Schema.XmlSerializers.dll"
I'm running into a few problems here.
If I just run ILMerge as shown above, it works, and I get ClrMergedAssembly.dll. I can install ClrMergedAssembly.dll on SQL Server 2005, but when I try to use it, anything that uses XmlSerializer gives me an error like:
A .NET Framework error occurred during execution of user-defined routine or aggregate "Whatever":
System.InvalidOperationException: Cannot load dynamically generated serialization assembly. In some hosting environments assembly load functionality is restricted, consider using pre-generated serializer.
This is the same error I get when not generating the XmlSerializer at all. I found this excellent blog entry stating that sgen needs to be run again after ILMerge, but doing so creates two problems. First, I really need sgen to be run only on CalcLibrary.Schema.dll. Running it on the whole assembly will fail badly; in fact, that is why CalcLibrary.Schema is separate from CalcLibrary in the first place. Second, having the serializer be separate somewhat defeats the purpose of using ILMerge at all: I want just one DLL to deploy. Are there any solutions here?
The ILMerge.doc file that comes with the ILMerge installation seems to suggest that adding /union and/or /closed might solve some problems. But, using either /union alone or /union along with /closed causes ILMerge to fail with the following error:
An exception occurred during merging:
Unresolved assembly reference not allowed: CalcLibrary.
A stack trace follows the error. My suspicion is that, because ClrIntegration must reference the database version of CalcLibrary rather than the VS2008 solution's version, ILMerge cannot find the type and, therefore, cannot complete the union even though CalcLibrary.dll is the same library. Is my suspicion correct? Is there any way around this issue?
You can't. The framework code always looks for the sgen generated classes in a different assembly - the one named with .XmlSerializers suffix - and it is hardcoded in the framework. Check with your decompilation tool of choice.
I have a solution I am migrating from Visual Studio 2005 to 2010. Inside the IDE on developers machines, everything works fine, but my build server (with CC.NET) is giving me an error.
I have around 10 projects, 3 of which are not strong-named due to using unsigned references.
One of them (signed) has an InternalsVisibleTo another of the signed projects.
In the IDE I use Debug/Release configuration, which delay-sign all of the projects that are to be strong-named.
I also created Debug_Signed and Debug_Unsigned configurations (and the corresponding Release_*), which only build the corresponding projects.
In my build server I use the actual private key to build first the Debug_Signed configuration, and then call MSBUILD again on the Debug_Unsigned configuration with SingAssembly=false.
This worked perfectly fine using .NET 2.0 SDK, but now the first MSBUILD works fine, but then the second MSBUILD tries to rebuild the signed projects (since they are referenced by the unsigned projectes), and I get an error about one assembly having an InternalsVisibleTo a signed assembly while the generated assembly is not signed:
error CS0281: Friend access was granted to 'Sic.Gateway.Customers, PublicKey=0024...4bbe', but the output assembly is named 'Sic.Gateway.Customers, Version=2.0.0.796, Culture=neutral, PublicKeyToken=null'. Try adding a reference to 'Sic.Gateway.Customers, PublicKey=0024...4bbe' or changing the output assembly name to match.
What I would like is the second MSBUILD to use the reference assemblys that were just built by the first MSBUILD instead of trying to rebuild them.
The build server just has the .NET 4.0 runtime (not the SDK) and I had to copy two .targets files (for SQL/CLR and web applications). But since everything seems to build fine, I don't think that would be a problem.
Does anyone have any idea of what I can do?
Thanks,
Luis Alonso Ramos
(copied as answer from Luis' comment above)
When running MSBUILD for either the unsigned or signed assemblies I was specifying three properties:
SignAssembly=true\false;DelaySign=False;AssemblyOriginatorKeyFile=D:\blah\blah.snk
The thing is these properties applied to the whole solution, overriding the settings from individual projects. What I did was specify only the DelaySign and key file properties, without specifying SignAssembly. That way, the assemblies that are to be signed are still signed (with the new non-delay-signing settings), and those that shouldn't be signed are not.