Recently I am facing a problem with msbuild.exe by building a dll. My idea is to call the msbuild from DOS command line to automatically create the DLL without opening MS Visual Studio. The command line (as example) I am using is:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe C:\example.sln /p:Configuration=example_config
The problem is, even I changed the files in this project (outside of MS Visual Studio), it seems that msbuild.exe isn't able to recognize the change and still output the old dll based on the old files.
Also I tried to delete the output DLL beforehand, but still the same result. The command line from DOS delivered the old dll.
If I open Visual Studio and build the output manually, the problem won't happen.
I checked around in web but can't find a feasible solution for this. Someone mentioned that it could be problem of MS. Actually, I was also not facing this problem under Windows XP.
I am using
List item
Window 7 64-bit version
MS Visual C++ 2010
The solution contains several sub-projects which deliver libary as output separately.
If anyone can help, I'll be very thankful.
You can build your project by calling Visual Studio 2010 from the command line. To build without opening Visual Studio, call "devenv.com" (command-line-friendly Visual Studio executable) to build the project. More info regarding devenv command line usage can be found on MSDN.
Customize the following command and run it from the command prompt to build your project:
"%VS100COMNTOOLS%..\IDE\devenv.com" "full-path-to-solution" /Rebuild "desired-configuration" /Project "full-path-to-project"
Related
I created a complex program based on different modules which load after program has started. The program structure is very similar to QtCreator. Frankly speaking I've taken part of code from QtCreator. (plugin management system)
I'm trying to debug my program with Visual Studio 2013. Very often the debugger doesn't show correct values and skip lines of code or jump from a following line of code to the previous line. It seems to me that pdb file doesn't correspond to the proper file. How is that may be possible? Should I set specific or additional parameters for debugging Qt programs in MSVS 2013? What might be the reason of such behaviour of debugger?
ps. I installed Qt 5.4.1 for Windows 32-bit (VS 2013, 705 MB) along with Visual Studio Add-in 1.2.4 for Qt5 (156 MB) properly.
I've made cleanup and rebuild several times, tried to delete related files after compilation - it didn't help.
Go to project property pages-> C/C++ ->Optimization. Set 'Optimization' property to 'Disabled(/Od)'.
Thanks to SaZ!
I have the following scenario:
Visual Studio 2010 solution with one WPF-project, output file is "Tool.exe"
Eclipse Shared Library project, output file is "Tool.dll"
I place the dll in the same folder as the exe and then I try to debug using Visual Studio; but I get the following error:
Error while trying to run project: Could not load file or assembly 'Tool' or one of its dependencies. The module was expected to contain an assembly manifest.
I have managed to find a solution to the problem, rename the dll, apparently the exe and dll cannot have the same name. My question is, why is this error occuring in the first place? Why does the name of the dll affect Visual Studio? The error occurs before even trying to pinvoke the dll. If I run my application without Visual Studio it works perfectly, but I want to be able to debug it of course.
Right now renaming the dll is plan B, but before I do that I would like to know if there is anything else I can do to fix this problem?
Thanks in advance.
I found simple steps to solve this error.
1- change your windows.
2- install Symantec Endpoint Protection Client 12.1.6318.6100 x32 or x64 bit.
You can geting it software(32 bit) from link: (ftp://192.168.168.215/Public/Antivirus/Symantec/Symantec Endpoint Protection Client 12.1.6318.6100 x86.rar)
drag and drop it to your software(IE ,....) to work.
3- install all driver on your computer.
4- install Visual studio.
End
Hi have a problem with VisualStudio 2010 and the QT5 plugin, it seems that VisualStudio doesnt recognize the QT Library (despite i have installed the plugin and followed the whole procedure).
This is what I see:
https://www.dropbox.com/s/yyzvfev0zoj8x9n/visualstrudel.jpg
So the IDE highlights the QT stuff like if the files were not present, and Intellisense is not working. But, If I compile the application, it compiles without error and works like a charm.
What could be the cause of the highlight/Intellisense issue?
You cannot launch Visual Studio 2010 directly.
You will need to launch the QT 5.0.1 for Desktop(MSVC 2010) command line from Program Files->Qt 5.0.1->5.0.1
After which you will need to run the vcvarsall.bat and devenv after.
x:\program files(x86)\Microsoft Visual Studio 10.0.\VC\vcvarsall.bat
x:\program files(x86)\Microsoft Visual Studio 10.0.\Common7\IDE\devenv.exe
This is applicable to VS2012 and Qt4.5.0, though I believe Qt version does not matter.
I am not sure if it is the same/similar to VS2010, but I stumbled upon this post while looking the answer to the same question for VS2012.
Here is what you can do:
Right-click the project in your solution and select Properties.
Select Configuration Properties -> VC++ Directories.
Edit Include Directories entry.
Add $(QTDIR)\include\QtCore and any other (required by your project) Qt folders to the list (it depends what Qt headers you are using).
This has to be done to every project in your solution that uses Qt, unfortunately.
Now, there is another note:
We were transferring our solution from VS2005 to VS2012 and that problem happened to me when I converted the solution 2005->2012 BEFORE setting the QTDIR environment variable.
When I re-converted the solution again (AFTER *QTDIR* variable was created) the problem didn't appear. So make sure you have this variable before you open/convert your solution for the first time.
Based on the previous note, I believe that some information related to the issue is stored in one of the following files: .sdf and/or .v11.suo.
So closing VS, deleting these files and opening VS again might help. Just back them up before you do it - I haven't tried it myself (I just re-imported the whole solution which generated these files anew).
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 recently create a couple of VSPackages for some Visual Studio extensions (menu bar/command). I compiled them correctly yesterday, checked into TFS (i'm the only one touching this project, FYI). I had already installed these extensions and were working fine. Today it doesn't compile! I get the following error:
Exception has been thrown by the target of an invocation.
This doesn't tell me anything, so i fired up Visual Studio with the following command:
devenv.exe /Rebuild > out.log
In my out.log, I see the following:
C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets(420,5): error : Exception has been thrown by the target of an invocation.
I have been stuck on this for hours and can no longer build these VSPackages. Anyone? This is really frustrating. I have already tried cleaning project/rebuilding/build using Visual Studio itself (not command line)
I've experienced this issue several times in both vs2010 and vs2012, and manually deleting the "bin" and "obj" folders from the project then doing a "rebuild" normally does the trick.
Further to the answer provided by the OP, I will provide it here for completeness instead of relying on the external link remaining live:
Quoted directly from the MSDN forum answer:
Do you happen to have these extensions installed to the AllUsers
location (i.e. %VSInstallDir%\Common7\IDE\Extensions)?
You mentioned in your initial post that "I had already installed these
extensions and were working fine."
The task that's failing (based on the line number in the targets file)
is the UninstallExtension task. The only reason I'm thinking this task
would execute and fail in your situation is if you're building an
extension that's already installed to the Common7\IDE\Extensions
directory.
Regards, Aaron
I find myself on this question because of exactly the same build issue of a VSIX Installer Project for our project templates. This solved my issue.
Indeed, I uninstalled the prior version of our templates and the build occurs without issue.
Have you double checked that all of your projects are using compatible framework versions?
As in you can't use a .Net 4.0 assembly in a .Net 3.5 project.
Is the project linked with source control like TFS? If so then take latest from TFS and try again.
Are you running Visual Studio as Administrator?
Maybe you have insufficient rights for some file (copy/move/delete) especially in bin or obj folders.