I'm trying to set up some build scripts for continuous integration and I'm finding something weird.
My solution compiles fine from Visual Studio 2010, but fails with an error when I build the exact same thing from the command line with MSBuild.
Here's the error I get from the commandline build.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.WinFX.targets(269,9):
error MC1000: Unknown build error,
'Cannot resolve dependency to assembly 'Microsoft.Windows.Design.Extensibility, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.'
[C:\Dev\Market Watch\src\Console\MarketWatch.Console\Rbnz.MarketWatch.Console.csproj]
I've checked through all my source code for references to Microsoft.Windows.Design.Extensibility and haven't found any at all. I've also checked all the binaries we reference from this project, including some DevExpress libraries.
My MSBuild commandline looks like this:
MsBuild.exe c:\Dev\MarketWatch\src\Capture\Capture.sln
/t:rebuild
/verbosity:quiet
/filelogger
/fileloggerparameters:LogFile=c:\Dev\MarketWatch\build\Logs\capture.msbuild.log
Is there something missing that I should include on the MsBuild commandline to make commandline builds work just the same as those run by Visual Studio?
Update 14/4
I'm getting these errors despite running the build script from a Visual Studio command prompt.
I hope you solved the problem, but for future reference:
I just had the same problem, and it comes from DevExpress '.design' assemblies. You're actually not supposed to reference those in your project. Remove all references to DevExpress assemblies ending with '.design' and it should work.
You should initialize paths to find assemblies, tools and so on. Call vcvarsall.bat before calling msbuild:
call "%ProgramFiles%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
Or open VS2010 command line console and call your script from it. Both actions has the same effect.
EDIT: I couldn't understand one thing - google for your question says that you use Reflection in a wrong way, and one of possible solutions is described here. Am I right?
I recently encountered the same issue.
The Error was thrown on our VSTS-BuildAgent.
After following all advices from Devexpress sites (including Project-Upgrade), the Error was still there.
To be honest, we are mixing WinForms and WPF for a smooth migration from Winforms to WPF, so basically not an everyday-problem.
Anyway, i was able to fix this, by adding all needed references to WPF-Project again, even if they are all already referenced in the Start-Project, which is Winforms.
After this move, the BuildAgent was able to succeed the Build.
Related
What to do to solve "The “GetDeploymentPathFromVsixManifest” task failed unexpectedly" when trying to debug a VS extension project??
Same question was already asked multiple times with different source reasons, all for VS2017 usually for upgrading VS extensions from VS2015, and it should have been solved with VS 2019. Yet, it just popped up.
The "GetDeploymentPathFromVsixManifest" task failed unexpectedly.
System.TypeLoadException: Method 'get_JoinableTaskFactory' in type 'Microsoft.VisualStudio.Sdk.BuildTasks.ExtensionEngineHost' from assembly 'Microsoft.VisualStudio.Sdk.BuildTasks.16.0, Version=16.9.2017.12405, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' does not have an implementation.
at Microsoft.VisualStudio.Sdk.BuildTasks.ExtensionManagerUtilities.GetExtensionEngine(ISettingsManager manager, Boolean deletePendingUninstalls)
at Microsoft.VisualStudio.Sdk.BuildTasks.GetDeploymentPathFromVsixManifest.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
I have tried all the solution for the same error found on SO, so far to no avail. I am using VS 2019 Community 16.9.2, updated all packages, downgraded some to try, nothing really changes this error.
This is my first attempt on VSIX and I just downloaded an existing project from github and compiled it.
The github project is working (probably) since the extension is available on the marketplace.
Any other suggestions? Searches on this error in combination with the JoinableTaskFactory dont return exactly many results.
For me the solution was to do at least one of the following steps:
Delete the obj-folder in the project
Execute Reset the Visual Studio 2019 Experimental Instance. You can find this tool when you search it in the windows search bar.
Clean and Rebuild the project
Sometimes it helped if I did only one step and sometimes it only worked after doing all the steps.
I couldn't find out if there is a specific pattern behind, but doing all of the above steps always fixed the error for me.
Another issue where I got the same error was if there was the wrong external program selected under Project Properties -> Debug -> Start external Program. For VS2019 I need to select C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv.exe
If I switched between Visual Studio Versions, then sometimes a different Visual Studio version was selected.
Uncheck: "Deploy VSIX content to experimental instance for debugging"
in solution properties->VSIX
Also Update installed NuGet packages.
I am trying to clean and rebuild a solution file with multiple projects from the command line using MSBUILD. For some reason my build fails (about 10% of the built projects fail) and I get multiple errors which all look like:
error CS0234: The type or namespace name 'foo' does not exist in the namespace 'bar' (are you missing an assembly reference?)
Now if I clean and rebuild the same solution file from Visual Studio 2010 with the exact same configurations it will build successfully with no errors.
Is there a difference in the setup or configuration of MSBuild from Visual Studio that needs to be changed that I am not aware of?
I just had to deal with this issue and it turns out that msbuild likes to move built binaries into the binaries\release directory and reference those instead of the projects themselves when it builds things. After building it copies the files to this directory. This explains why it works in visual studio and not msbuild (I'm currently using TFS 1010).
In my case I had an old binary version of a dll being referenced by a project that was being built after the one that should have generated the correct file. The old one (binary) was overwriting the new one (built from source) as the solution referencing the binary one was being built later in the build.
I assume there's a difference in how the project is built, because Visual Studio does not run MSBuild, as it rather hosts the build engine itself.
This was answered here.
However, I've had similar problem.
In my case the project referenced an external library, which was placed in the project's child directory, unluckily named "packages".
After running MSBuild the folder's content was deleted, supposedly to be downloaded again by Nuget.
The obvious solution was to rename the folder and it worked.
Summary: Set Debug/Release mode in Visual Studio to the same settings as MSBuild to check for compilation errors.
I encountered the same problem:
Tried deleting all "bin" and "obj" folders.
Made sure all related projects are indeed being referenced and not just liked to compiled dlls. ex. Project B references A. Remove A from solution. Then add again. B would then reference A but via compiled dll only. Remove reference and re-add the project.
Finally switched to "Release" in Visual Studio. Turns out I had conditional compilation in some code (eg. #if DEBUG). So what was running in MSBuild and Visual Studio were actually different hence the error "The type or namespace name 'foo' does not exist in the namespace 'bar' (are you missing an assembly reference?)"
Try checking the paths to the references that MSBuild can't find in the non-building library's project file. Sometimes when you use VS or ReSharper to automatically add a reference for you the path ends up being to the \obj directory. VS seems able to cope with this, but MSBuild not so much.
For me the problem was that the some projects in the solution were not included in the build configuration for the solution. Those projects were dependencies for the projects in the build configuration, so all the projects in the solution failed.
After marking the dependcies projects with build in the solution configuration the msbuild ran successfully.
My issue was found in the solution file.
Remove all lines which reference 'ANY' for CPU and leave the 64 bit ones in.
In my case I had one PCL referencing another PCL with different targets. Visual Studio showed me a warning in the references list of the first library, but compiled the solution, whereas MSBUILD refused to compile. I fixed the problem by retargeting the PCL. Hope this helps somebody.
See my answer here.
Basically - Try running msbuild in a new cmd window everytime as a temporary workaround.
I was facing a similar issue. But after spending a lot of time, I finally came up with a solution (that performs similar to VS)
Use the following command to build your solution
"msbuild.exe project.sln /restore /t:Build /p:Configuration="Release";RunCodeAnalysis=False;RestorePackagesConfig=true”
I am trying to build MSIs in a TFS Build by shelling out to DEVENV.exe (since MSBUILD does not support VSPROJs). In any case, my first installer project builds fine, the second one fails. If I reverse the order, same thing happends (i.e. the error does not follow the project). Looking at the output, I get the following errors:
Deserializing the project state for project '[MyProject].dbproj'
[MyProject].dbproj : error : Error HRESULT E_FAIL has been returned from a call to a COM component.
Also, I get:
Package 'Microsoft.VisualStudio.TestTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed to load
It looks as though the first build tries to serialize the DB project (and it says it succeeds, but there is no DBML file anywhere). Then the second build tries to deserialize the DB project and fails.
I've tried resetting env settings (using the /resetusersettings flag) as well as using the /resetskippkgs flag. Nothing works.
Any ideas?
When you shell out to DevEnv, are you building that specific project (.vdproj file), or are you building the solution? It sounds like VS is trying to open the solution on the build machine and the database and test project systems aren't present.
Have you considered porting your setup project to WiX?
Start simple. Unless you're well versed in the problem you're trying to solve it's usually best to try it "by hand" before getting it running as part of a TFS build. RDP into the build server and try running the necessary commands at the command line and see what happens. You can even go simpler than that and RDP into the build machine and load Visual Studio and build it.
Bottom line is that if you can't get it to build within Visual Studio or at the command line by calling devenv.exe it won't work as part of the team build.
I am using the below Exec task to do precisely what you are doing as part of a TFS build. So I know this works. Your platform and configuration may vary depending on what you're building. The nice thing about this is that you'll have a log file at C:\Temp\MSIBuildOutputLog.txt that you can analyze for additional errors and information.
<Exec Command=""C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" "$(PathToSolution)\solution.sln" /Build "Release|Mixed Platforms" /out "C:\Temp\MSIBuildOutputLog.txt"" />
One important thing to note... There is a bug in VS2010 which causes MSI generation to fail when you try to run it at the command line using devenv.exe. This took me days to find and figure out, but you need this hotfix. Worked like a charm...
http://archive.msdn.microsoft.com/KB2286556
Actually it's the deployment projects that don't support msbuild. FWIW, this is all deprecated in the next release of Visual Studio so you might want to start looking at InstallShield Limited Edition and/or Windows Installer XML now before spending too much time on dead end, broken technology. Both of these alternatives have proper MSBuild support aswell as many other improvements.
It would be perhaps better and quicker to adopt WIX (Windows Installer XML) which is the technology MS now recommends to use within VS/MSBuild/TFSBuild environment to crate MSIs.
It is relatively easy to setup and integrate within your VS Solutions. It uses XML based files to describe your MSIs and uses these files to create your MSIs when you compile.
I would start by downloading Wix from http://wix.codeplex.com/
Once installed you would be able to use the VS2010 integration of Wix based projects to create MSIs. To get started quickly simply add a new Wix project to your solution and reference the projects whose output you wish to combine into an MSI. Next you can run a tool called "Heat" which is included with Wix toolkit to generate the XML files by scanning your projects.
Once you have these XML files, add them to your Wix project and compile.
I have a solution containing my main project and a test project using NUnit. Everything compiles but when I run NUnit I get the exception below after the tests load, and the tests fail. I've added the main project as a reference, and I have $(ProjectDir)bin/Debug/$(TargetName)$(TargetExt) in the arguments for NUnit in the external tools setup, with a blank initial directory.
MyMainProjectTests.Database.TestAddDelete:
System.BadImageFormatException : Could not load file or assembly 'MyMainProject,
Version=1.1.1.0, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. An attempt was made to load a program with an incorrect format.
TearDown : System.Reflection.TargetInvocationException : Exception has been
thrown by the target of an invocation.
----> System.BadImageFormatException : Could not load file or assembly
'ChickenPing, Version=1.1.1.0, Culture=neutral, PublicKeyToken=null' or one
of its dependencies. An attempt was made to load a program with an incorrect
format.
After scouring for hours the only thing I've found is a bug in VS2005 which mentions the /bin and /obj directories, but the answer provided didn't help.
Any solutions?
Instead of setting up NUnit as an External Tool, I set the unit test project as the StartUp project. In the project's Properties screen, set the Start Action to "Start external program" and point it to nunit.exe. In the Start Options section, I specify the test assembly (no path necessary) in the "Command line arguments" box. At this point, simply press F5 to start up NUnit.
Use the nunit-x86.exe instead of nunit.exe as your runner.
A better longer term solution may be to buy ReSharper that includes a much nicer test runner for NUnit that fully integrates into Visual Studio. It auto detects your .NET project type (x68 or x64). ReShaper comes with tons of other features of which unit testing is just one. Their test runner also integrates with their DotCover code coverage analyser.
You may find that you'll need a later version of Visual Studio to use ReSharper. The latest version works with Visual Studio 2013 Community Edition that you can get for free though I understand you may have issues upgrading some project features from such a rather old VS2005 project.
I don't have any affiliation with ReSharper.
Are you running on x64? You will get that error if loading a x64 bit from x86 and vise versa. Also, the path you are trying to create should be the $(TargetPath) macro.
Just set "Platform target" of Tests project to "x86".
Is your main project a .exe or a .dll? Older versions of .NET couldn't reference an .exe, so that might be the problem.
In either case, I'd expect problems if the main assembly didn't end up somewhere accessible by your test assembly (for example, in the same directory). You could check that, and if not make it so, perhaps by having Visual Studio copy the referenced (main) assembly to the local directory.
The "An attempt was made to load a program with an incorrect format." makes me wonder if the "missing assembly" theory is right, but without more info, it's the best guess I can think of.
Go the the NUnit install (example: C:\Program Files (x86)\NUnit 2.6.3\bin) location and open nunit-86.exe.
I have a DSL Tools solution.
I need to add a weak-named reference to this project.
Because the DSL Tools project DLL is strong-named i cannot used the weak-named DLL.
I cannot make the DLL strong-named because i cannot recompile it.
I tried to make my DSL Tools project DLL weak-named by going to the Dsl and DslPackage project properties and unchecked the option "Sign the assembly" in the Sigining tab.
Then i compile it.
The error list gives the following error
"gacutil.exe" exited with code 1
Looking at the VS2005 output window i see gacutil is being called
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\gacutil.exe -nologo -i "C:\Academy\ResearchAndDevelopment\FrontendGenerator\DslPackage\bin\Debug\vantyx.FEGenerator.DslPackage.dll"
After that i used the command prompt and the gacutil.exe error displays as this:
Z:\>"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\gacutil.exe" -nologo -i "C:\Academy\ResearchAndDevelopment\FrontendGenerator\DslPackage\bin\Debug\vantyx.FEGenerator.DslPackage.dll"
Failure adding assembly to the cache: Attempt to install an assembly without a strong name
I don't know why and how gacutil.exe is being called.
I looked at the project and solution properties and there is no option configured to call gacutil.exe.
I even looked inside every file for "gacutil.exe" but i found nothing.
What i really want is to be able to use the weak-named DLL that i cannot make strong-named.
As a result of this, i've been trying to make my DSL Tools DLL weak-named but i can't.
Any help on how i can workaround this?
Many thanks in advance,
Luís Filipe
Using runtime binding with reflexion is a good solution and works. The other solution I've implemented besides that one is to launch a separate AppDomain and have that AppDomain doing the loading of the assembly and running whatever methods you want. The downside of this approach is the extra complexity and performance. One really has to know what he is doing as he is in practice launching a separate .net application in Visual Studio's process space. The upside is that with some care, you can get type safety all the way.
With the exception of the answer written above,
All add-ins for Visual Studio must be strong-named.
One may workaround some of the issues by loading the assembly on run-time and using reflection to invoke methods.
Regards,
Luís