I want to hook up solution level pre build / post build events in VS 2011 for .net projects.
My action includes firing up batch file. (it is working fine for any individual project, but i want it for solution build process).
How to achieve this?
I have seen this question that uses macro for the same. But macro are dropped in VS 2011.
Another similar question suggest makefile project, that it is specific to C++.
This might be helpful. Take a look at that. You will have author a package for this though.
Related
I have run into a problem in a solution containing a WiX manged custom action project, which is also using MS RiSE Code Contracts. The problem is that the code contracts tools fail with the following error:
I found a few mutterings about this issue going back at least 5 years, but not even a hint of a solution or workaround.
As an experiment, I tried commenting out the WiX-specific targets as follows:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<!--<Import Project="$(WixCATargetsPath)" />-->
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
This allows the build to complete and the code contracts analysis/rewrite to complete successfully, however it obviously doesn't produce the correctly packaged self-extracting custom action. Since Windows Installer doesn't have any facility for managed code custom actions, WiX uses the trick of wrapping the managed code in an unmanaged wrapper which is a self-extracting archive containing the managed code custom action and its dependencies. It is a clever trick that lets us write custom actions in managed code, and it works very nicely. Until now.
I suspect what is happening is that the WiX build process is stuffing the managed code into an unmanaged wrapper, which becomes the project's primary output and which the Code Contracts utility then chokes on, because it is not managed code. I can't be certain because the code contracts build process isn't visible, so I can't see how it is working.
The above experiment makes me think that if I could somehow split the build process into separate parts, compiling the custom action code as a bog standard C# class library project, then doign the WiX packaging in a post-build event, I think the code contracts utilities would be able to process the code correctly. The problem is that I don't know enough about the Code Contracts mechanisms, or the WiX build process for that matter, to figure out what I'd need to do in the post-build event.
Would it be possible to somehow perform the WiX custom action packaging in a batch file or PowerShell script, which could be run as a post-build event? What would I need to do?
Check out the DTF.chm help file that comes with WiX, in the Development Guide it explains how to manually build the CA DLL with MakeSfxCA.exe.
I haven't done much "front-end" development in about 15 years since moving to database development. I'm planning to start work on a personal project using C++ and since I already have MSDN I'll probably end up doing it in Visual Studio 2010. I'm thinking about using Subversion as a version control system eventually. Of course, I'd like to get up and running as quickly as I can, but I'd also like to avoid any pitfalls from a poorly organized project environment.
So, my question is, are there any good resources with common best practices for setting up a development environment? I'm thinking along the lines of where to break down a solution into multiple projects if necessary, how to set up a unit testing process, organizing resources, directories, etc.
Are there any great add-ons that I should make sure I have set up from the start?
Most tutorials just have one simple project, type in your code and click on build to see that your new application says, "Hello World!".
This will be a Windows application with several DLLs as well (no web development), so there doesn't need to be a deploy to a web server kind of process.
Mostly I just want to make sure that I don't miss anything big and then have to extensively refactor because of it.
Thanks!
I would also like a good answer to this question. What I've done is set it up so that each solution makes reference to a $(SolutionDir)\build directory for includes and libraries. That way each project that has dependencies on other projects can access them and versions won't compete. Then there are post-build commands to package up headers and .lib files into a "distribution" folder. I use CC.net to build each package on checkin. When we decide to update a dependency project we "release" it to ourselves, which requires manual tagging, manual copying current.zip into a releases area and giving it a version number, and copying that into the /build of the projects that depend on the upgrade.
Everything works pretty great except this manual process at the end. I'd really love to get rid of it but can't seem to. Read an article from ACM about "Continuous Release" that would be really nice to have an implementation of but there isn't any. I keep telling myself I'll make one.
If I use "junctions" in the windows filesystem I can link "distribute" to "build" and then build a secondary solution that includes all the projects that are dependent on each other to build a product. When I did that though it encouraged developers to use it for active development, which discouraged TDD and proper releasing.
I am using Eclipse for C++ development on windows. I have also written a code generator that take an xml file and produces several C++ files. The project I am working on is currently setup to use the internal builder. What I would like to do is to run the code generator as part of the build process.
My problem is that I haven't been able to find a way to make Eclipse identify that the files are present (or have been updated) without 'Refeshing' the project. So although I can run the code generator as a pre-build step, the files generated aren't guaranteed to be included in the build.
Does anybody know whether there is a way to make Eclipse do a refresh after the pre-build step or something to that effect, using the internal builder?
Thanks
You can add a Builder to your project.
I'm not sure if this is possible using the internal builder of Eclipse. Refreshing has always been a problem there. But using external build tool, like Maven or Ant, works! I personally would switch to Visual Studio - there you never have such kind of problems
Although I have not tried this with CDT projects enabling the the Preferences->General->Workspace -> Refresh automatically helps me with Web & Java projects where code generation is involved.
we work under Linux/Eclipse/C++ using Eclipse's "native" C++ projects (.cproject). the system comprises from several C++ projects all kept under svn version control, using integrated subclipse plugin.
we want to have a script that would checkout, compile and package the system, without us needing to drive this process manually from eclipse, as we do now.
I see that there are generated makefile and support files (sources.mk, subdir.mk etc.), scattered around, which are not under version control (probably the subclipse plugin is "clever" enough to exclude them). I guess I can put them under svn and use in the script we need.
however, this feels shaky. have anybody tried it? Are there any issues to expect? Are there recommended ways to achieve what we need?
N.B. I don't believe that an idea of adopting another build system will be accepted nicely, unless it's SUPER-smooth. We are a small company of 4 developers running full-steam ahead, and any additional overhead or learning curve will not appreciated :)
thanks a lot in advance!
I would not recommend putting things that are generated in an external tool into version control. My favorite phrase for this tactic is "version the recipe, not the cake". Instead, you should use a third party tool like your script to manipulate Eclipse appropriately to generate these files from your sources, and then compile them. This avoids the risk of having one of these automatically generated files be out of sync with your root sources.
I'm not sure what your threshold for "super-smooth" is, but you might want to take a look at Maven2, which has a plugin for Eclipse projects to do just this.
I know that this is a big problem (I had exactly the same; in addition: maintaining a build-workspace in svn is a real pain!)
Problems I see:
You will get into problems as soon as somebody adds or changes project settings files but doesn't trigger a new build for all possible platforms! (makefiles aren't updated).
There is no overall make file so you can not easily use the build order of your projects that Eclipse had calculated
BTW: I wrote an Eclipse plugin that builds up a workspace from a given (textual) list of projects and then triggers the build. That's possible but also not an easy task.
Unfortunately I can't post the plugin somewhere because I wrote it for my former employer...
I have a fairly complex Xcode project and I want to add Qt to it. I know that I can create a new project using qmake -spec macx-xcode project.pro but I don't want to have to hand configure my old project over the auto generated Qt project. Is there another option?
[edited in a more general question below]
It seems like it would be easier to simply use qmake as my build system. Hence, adding my old project build process to the .pro file and use that to generate a new .xcodeproj? I would only do this if I could comprehensively configure the .pro file so that I don't have to hand configure the .xcodeproj - is this doable? I really don't want to have to mess around with hand configuring the .xcodeproj each time I run qmake.
Essentially, is qmake (or a meta-build in general) a valid substitute for a normal build system, such that I don't need to tweak the resulting build system generated by qmake?
Are there better resources besides the manual and tutorial provided by Trolltech? I'm concerned that wikipedia says that qmake is primarily for internal use and not well documented.
One of the main points of using Qt is the portability of the Gui. It only makes sense to extend this feature to your build process by using qmake and allowing users/developers generate whichever build system they want to use (make, visualstudio, xcode).
No, qmake is not well documented and more poignantly there are not manifold examples like there are for make. But, it is similar to make and should be intuitive. Why not absorb the overhead to learn it and pass the benefit on to your users/developers?
Build an empty xcode project with qmake and incorporate the compiler settings to your existing project from the generated Makefile. Of course, you will have to set up your existing project to run qmake as a pre-build step if you are using Qt-specific extensions.
What do you think is the easiest method for integrating established projects with Qt?
That depends on the nature of your work. I wish I could have given a more specific answer here but I really can't. Also, are you using Qt professional? In that case, you can get support (at least that's how it was, during 3.3 when I last worked on it for anything production-quality). If all you care about Qt is the graphics part, I'd say don't bother changing your build system, rather see to it that you get the code to compile and link and run just fine. But, if you are going to use signals and slots and what not -- think about moving over.
Would you recommend I do the xcodeproj merge I asked about and which you answered, or should I start from scratch with qmake like I edited a question about?
Again, look at the size of your project. Assuming a fairly complex project, I'd hazard a guess that you have about 2/3 man-days worth of effort to rewrite the build system? Is this project a serious one, something that will be maintained over a period of time? Is this cross-platform? Will you be using Qt throughout?
If there is an overbearing reason to feel that Qt is the way forward I'd suggest that you start using their build system.
It's really, really, really nice to have a single IDE and debugger that works on all the platforms you are writing for, but I have found that it's also pretty nice to just use the native tools.
Once you put in the time to learn each build system, it's pretty easy to maintain the projects to a very precise degree.