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.
Related
So coming across a very strange issue with MSbuild using TFS 2015 build definition.
The web application I am trying to build has multiple csprojs that are used as class libraries throughout the application and of course my actual web application.
Bellow are the MSBuild arguments I am passing through currently to get a fully completed build.
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False /p:OutDir=C:\Agent\_work\1\s\Application\Package\bin\
/p:WebProjectOutputDir=C:\Agent\_work\1\s\Application\Package\WebSite\
/p:NoWarn=0067
/v:Minimal
What I would actually like to do is the following.
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False /p:OutDir=C:\Agent\_work\1\s\Application\Package\Website\bin\
/p:WebProjectOutputDir=C:\Agent\_work\1\s\Application\Package\WebSite\
/p:NoWarn=0067
/v:Minimal
The issue I run in to is after the first assemblies are run and placed in the bin folder it then works on the main webproject csproj and throws a unable to locate file for copy message.
I don't understand why this would be the case? Is it because MSBuild is expecting the bin folder to be empty/not there?
Am I missing something in the build order or different Argument needs to be passed. I have also to tried 'outpath' as well.
In the second arguments, the "OutDir" path is the same with "WebProjectOutputDir". This cause the issue since MSBuild will clean the "WebProjectOutputDir" folder before run "_WPPCopyWebApplication" task which copies files to "WebProjectOutputDir" folder. That means the files generated in "OutDir" during the build will be cleaned because it use the same path with "WebProjectOutputDir", so the task will cannot locate the files to copy.
To avoid this issue, you'd either change the "OutDir" different with "WebProjectOutputDir" or add one more arguments:
/p:CleanWebProjectOutputDir=False
I want to build a project with a particular named Build Configuration, let's call it Conf-A.
This is running as an MSBuild step on TeamCity. When the build runs, it spits out:
The OutputPath property is not set for project ... You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.
This project is part of a hulking great solution we load on our dev machines.
The error makes sense for my situation, since I'm building just the proj file, but I don't want to use the solution file since I'm trying break-up this monolithic app.
I want the build-server to treat this project as it's own component, even if for the moment it is part of a solution and has references to other projects (assemblies) in the solution.
Must I build this via a solution file?
I could potentially copy the solution file and prune off all the other projects that are not required, but that's more complexity.
(Maybe the error is a red-herring).
you dont need to build a sln. Its like the error says. You just havent specified a value for the variable OutputPath in your msbuild. You can add it to your files or you can pass it in at the cmd line - msbuild someproj.proj /p:OutputPath=C:\notallovermydrive
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...
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 ;)
I have written an MSBuild task that makes use of third-party assemblies.
When I use the task in my project, MSBuild complains that it can't load the third-party assemblies (not surprisingly).
Where should I place the third-party assemblies so that they are available to MSBuild. I tried adding project references to them without success.
I'm not sure if I expressed my problem very well, but now I've found the solution.
In my .proj file, I reference my custom task with the following syntax...
<UsingTask AssemblyFile="..\lib\MyCompany.MSBuild\MyCompany.MSBuild.dll" TaskName="CreateDatabase" />
My CreateDatabase task relies on various 3rd-party assemblies. However, some of these are only referenced via reflection, so weren't included by default in the folder "..\lib\MyCompany.MSBuild".
I had been trying to get the task to work by placing the required assemblies in the same directory as the .proj file invoking the task.
However, what I should have been doing was putting the assemblies in the referenced task directory "..\lib\MyCompany.MSBuild\".
Simple!
You could add them to the GAC (Global Assemby Cache). This only works if it is strongly named.
You could also make sure that you have marked them with copy local = true when you added the reference in the project.