Is there a way to compile a .vbproj or .csproj project file directly, just like Visual Studio does?
When you compile in Visual Studio, the "output" window shows the actual call to the compiler, which normally looks like:
vbc.exe [bunch of options] [looooong list of .vb files]
I would like to programatically call "something" that would take the .vbproj file and do whatever Visual Studio does to generate this long command line. I know i could parse the .vbproj myself and generate that command line, but I'd rather save myself all the reverse engineering and trial-and-error...
Is there a tool to do this? I'd rather be able to do it in a machine without having Visual Studio installed. However, if there's a way to call Visual Studio with some parameters to do it, then that'll be fine too.
I looked briefly at MSBuild, and it looks like it works from a .proj project file that i'd have to make especially, and that I'd need to update every time I add a file to the .vbproj file. (I did look briefly at it, so it's very likely I missed something important)
Any help will be greatly appreciated
MSBuild is the easiest way to go. For instance:
msbuild /property:Configuration=Release MyFile.vbproj
MSBuild can also take your solution file and use it to do the compile.
You can use either MSBUILD or CSC. MSBuild, which as you mentioned, does use your project and solution files. CSC will compile specific files, or all files in a specific directory tree.
You should also look at automating your builds with NAnt and/or CruiseControl.net.
Also, here is an example on how to compile your code without visual studio using CSC.
http://blog.slickedit.com/?p=163
Just so you know .vbproj and .csproj files are MSBuild. So everything that you've read, you can apply to those files directly.
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
In project solution folder:
msbuild wpfapp1.sln /p:BuildProjectReferences=true
MSbuild is usually located in:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319
(or something similar, depending on the version)
csc.exe compiles files, msbuild compiles projects and solutions
At the top of a .vbproj file is a . Add this line to the property group to suppress the VB runtime:
<NoVBRuntimeReference>On</NoVBRuntimeReference>
MSBuild does the rest. No need to use the command line if you have the IDE.
Related
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”
Does anyone know if is possible to have a Visual Studio project created automatically from a msbuild .proj file?
Thanks
I've just been trying to do something similar. Basically VS2010 won't let me add a "*.proj" file to a solution. HOWEVER, I found that if I simply renamed it to be a vbproj or a csproj, then VS2010 would let me add it to a solution, and it seemed to invoke it correctly. (The vbproj seemed 'nicest' to me, in that it didn't have a redundant "References" sub-folder.)
It does seem odd that VS2010 seems unable to work with an ad hoc MSBuild project file, demanding instead one that is tied explicitly to a specific languade (C#, VB.Net, SQL, WiX, ...)
In my case, it simlpy had an Exec task in it to go and invoke Doxygen to build developer documentation. That is, it was pretty simple! I hope the same trick might work for you too!
Another option might be for you would be too look at the "Makefile" project type in VS2010 (its under C++); that would allow you to directly invoke nmake and do away with the proj wrapper completely.
I am new to Visual Studio Extensibility and want to make an addin/extension which shall do the following:
It should read all the files with a specific file extension (assume "*.ump").
It should process the text/code/whatever in the files.
It should create new Class/Code file with some code in it. [The code will be produced in step 2, just need to know how to do it?]
Yet, I have been racking my brains through extensibility, saw the single file generators .... and addins which go through ProjectItems and can detect the file extension,
BUT I HAVE NOT BEEN ABLE TO FIND a complete tutorial, guide or explanation as to how or what to do!!
Please help...
You don't want to read all files with a specific file extension in Visual C++ project nor standard Visual C# project. You may do that with hand-made MSBuild project (included in the solution).
In Visual C++ projects, there is a way to define custom tools. They are run as separate processes, so you can implement them in anything you want. Studio will ask you whether you want to define a tool (they are defined in special xml files; studio has dialog for editing them) when you add a file with extension unknown to it. In Visual C# projects, just manually write a MSBuild tasks and insert them into the project.
Do whatever you want. IIRC the generated files will have to be included in the project though. Well, for MSBuild, just tweak the project to your heart's desire, but in Visual C++ they have to.
You can combine MSBuild (csproj,vbproj) and VisualC++ projects in a single solution, so I recommend using separate.
If you ever find out you need to compile for different target where you can't use Visual Studio, you'll be glad that you have stand-alone tool you were just calling from Studio and not something that embeds in it.
I got a project, source code, etc, using SCONS. Could you recommend tools/ways to convert or integrate it in a Visual Studio C command line project ?
Hi this may be usefull http://www.scons.org/wiki/IDEIntegration#head-a0b9e629986abc8528bdd599bac43a22cd161bf4
I realize this doesn't directly answer your question but I'd reconsider against using SCONS. Native Visual Studio projects have too many advantages such as being able to use Incredibuild, Visual Assist et c.
Instead you might want to look at XPJ:
http://sourceforge.net/projects/xpj/
What it does is generates a vcproj from an XML file, which can also be used to generate a SCONS project if absolutely necessary.
If you are not convinced, you can custom command line project option in Visual Studio and have it invoke the SCONS build.
I've been using C/lex for a long time and would like to use F#/fslex now.
I'm comparably well off in C# and in the process of learning F#.
The only thing is that I can't see any project example or template where fslex is properly included in the Visual Studio build process.
Does anyone know where I can find one?
Lots of Greetings!
Volker
Unfortunately, there is no built-in item template for .fsl files, because FsLex is a part of PowerPack (so Visual Studio cannot expect that it will be installed). It would be definitely useful to have some template that could be installed with PowerPack!
Anyway, if you're looking for a sample project that uses FsLex (and has .fsl files as part of the project), then you can take a look at the F# source code (distribtued with the Visual Studio 2008 MSI/ZIP package). The project that contains .fsl is FSharp.Compiler.fsproj and on my installation, it can be found in C:\Programs Files\FSharp-1.9.9.9\source\fsharp\FSharp.Compiler. Surprisingly, it includes a lexer for the F# language itself :-).
To add FsLex item to the MSBUILD project (which is also Visual Studio project), it uses the following:
<FsLex Include="..\lex.fsl">
<OtherFlags>--lexlib Internal.Utilities.Text.Lexing</OtherFlags>
<Link>lex.fsl</Link>
</FsLex>
<Compile Include="lex.fs" />
In case you also needed FsYacc, here is an example (also from FSharp.Compiler.fsproj):
<FsYacc Include="..\pars.fsy">
<Module>Microsoft.FSharp.Compiler.Parser</Module>
<Open>Microsoft.FSharp.Compiler</Open>
<OtherFlags>--internal --lexlib Internal.Utilities.Text.Lexing
--parslib Internal.Utilities.Text.Parsing</OtherFlags>
<Link>pars.fsy</Link>
</FsYacc>
<Compile Include="pars.fs" />
Note that you need the FsYacc/FsLex command to invoke the custom tool, but also the Compile command which tells the compiler to include the produced fs file when building the project.
I'm using the free VS Shell until I finally threaten myself enough to finally buy the full VS, and unless I'm doing something wrong, (and I probably am) none of the normal solutions seem to work for me. What I do is add the following pre-build events to the project properties:
"C:\Program Files (x86)\FSharpPowerPack-2.0.0.0\bin\fslex.exe" "$(ProjectDir)\Lexer.fsl"
"C:\Program Files (x86)\FSharpPowerPack-2.0.0.0\bin\fsyacc.exe" "$(ProjectDir)\Parser.fsy" --module Parser
That seems to work well enough for me. Errors all go to the output window. If you're on a 32-bit machine, you would remove the (x86) from those paths.
Doing a little research it looks like they need to be separate. I found the following at this blog post ( http://blogs.msdn.com/chrsmith/archive/2008/01/18/fslex-Sample.aspx ) by Chris Smith:
Although you can add an F# Lex Specification file from the Visual Studio Add-In, to run fslex you will need to break to the command line. Fslex.exe is located in your F# distribution’s ‘bin’ directory.
Hope that helps.