Is there an option to ignore duplicate project GUIDs? Seems like the scanner hooks itself into the build process and creates a output project whenever a build is run on a c# project. Sometimes multiple builds are run, e.g. Silverlight, Portable libraries, RIA code gen, and these all cause the scanner to generate duplicates. I've tried to eliminate the duplicates from the msbuild by changing csproj files and target files, but that is not easy (some projects are built 3 times), and I think it would be simpler if there was just a switch to ignore duplicates rather than exclude them.
Had the same issue with my solution using Silverlight. The only solution I found, though ugly, was to do a Powershell script to remove duplicate directories. The contents seemed to be the same, a list of files to use for processing. I would like to +1 for the ignore flag.
Related
I am building a project on Github written in Objective-C. It resolves MAC addresses down to manufacturer details. The lookup table is currently stored as text file manuf.txt (from the Wireshark project), which is parsed at run-time, which is costly. I would prefer to compile this down to archived objects at build-time, and load that instead.
I would like to amend the build phases such that I:
Build a simple compiler
Run the compiler, parsing manuf.txt and outputting archived objects
Build the framework
Copy the archived objects into the framwork
I am looking for wisdom on how to achieve steps 1 and 2 using Xcode v7.3 as Xcode provides only a Copy Files phase or a Run Script phase. An example of other projects achieving similar goals would be inspiring.
I suspect that what you are asking is possible, but tricky. The reason is that you will need to write a bunch of class files and then dynamically add them to the project.
Firstly you will need to employ a run script phase to run various tools from the command line to parse your file and generate a number of class files from it. I would suggest looking into various templating engines. For example appledoc uses moustache templates to generate API documentation files. You could use the same technique to generate header and implementation files.
Next, rather than generating archived objects an trying to import into a framework. I think you may be better off generating raw source code, adding it to a project and compiling into a framework. Probably simpler in the long run.
To automatically include the generated code I would look into (which means I haven't actually tried this :-) adding a folder reference to the project rather than an Xcode group. Folder references are an option in the 'Add files to ...' dialog.
Folder references refer to a directory and automatically add the entire contents of that directory to a project. So you can use one to point to the directory where you have generated the source code. This is a much better option than trying to manipulate the project or injecting things into an established framework.
I would prefer to parse the file at runtime. After launch you can look for an already existing output, otherwise parse it one time.
However, I have to do something similar at Objective-Cloud. I simply added a run script build phase and put the compiler call into it.
We have an MSBuild .proj file that is used to build and run lots of projects. That have file references to one another. Due to the fact that it is file references, we maintain the list of Project Dependencies on the solution, so that MSBuild is able to identify the order to execute projects in.
We had an issue recently, where our US development team added a new reference to one project, but didn't update the dependencies list. This builds fine for them locally, and on the server. However for the UK team, the build consistently failed for all developers.
I'm trying to understand why this was the case. The only thing I can think of is that our Culture causes the build order to be slightly different when two projects are essentially ranked at the same level. i.e. If Project A and B are perceived to have the same dependencies, then the order the two build in is arbitrarily determined, and this might be different in the UK culture vs the US culture.
That said, my machine (it broke for me) has the Region Format set the English US. And Location UK.
Does this sound feasible? or is there a better explanation for this?
Changing the culture will not fix the issue where you're making a file reference on a components output rather than a project reference to the project that will build the assembly.
Solution files do map dependencies and would help MsBuild determine build order. When MsBuild processes a solution it will first convert it in memory to MsBuild xml format, then it will determine project order by listing the dependencies, then determine if a project needs to be rebuilt by comparing the last update time of the input files to the output files.
When you have a project reference within a project (in a project, open the References folder, remove references to output assemblies and instead reference the project itself). This will modify the project file replacing Reference item groups with ProjectReference item groups. This allows MsBuild to make this determination on a project level and resolves the issue of having to manually configure the project build order.
As the title says, I want to output 2 .msi files from one project (one is per-user, and the other is per-machine). I have seen in this thread that it can't be done in some conventional way, but perhaps there is a way to do so as some kind of hack in post-build.
I only need to rerun compilation and linking after the original build with slightly changed command line (actually, I need only different Product.wxs file). However, my light and candle command lines are huge, and I would risk making my project hard to maintain if I would hard-code them.
So, in conclusion, I need to know if there is a way to write a command line that would behave the same as Votive does when creating its build command line (getting all the files in project, linking them, passing project dependencies...), only in post build.
P.S.: I also had an idea of getting the whole command line from Votive, and only changing the Product file, that would also help, so if someone has suggestion on how to do it...
Create multiple configurations of your solution / project and set a preprocessor variable to some value for one of the configurations. In your wix source, conditionally include whatever else it is that needs included based on your preprocessor variable.
I've been able to easily get all my headers and source files organized using filters like so:
source_group(Source\ Files\\network FILES
network/lobbylist.cpp
network/network.cpp
network/networkenet.cpp
network/networkfactory.cpp
network/networklinux.cpp
network/networkraw.cpp
network/networkwin.cpp
)
However, today I started adding Lua scripts to my project and found that, although no errors were displayed during project generation and everything seemed to be spelled correctly, CMake didn't add a new filter for the scripts in the solution at all.
source_group(Source\ Files\\scripts FILES
scripts/en_lang.lua
)
I also tried putting the group under the Header Files filter and under the project root, but no go. Does CMake simply not recognize or know what to do with non-.h/.hpp/.c/.cpp/etc files? Is there any way to get around this? Obviously I can still edit the scripts in a separate window or open it manually in VS, but having it right there in the solution explorer would be preferable.
You have to add the lua files to ADD_EXECUTABLE
First, I have a base assumption from watching Visual Studio compile things with its default .*proj files that, if you build the same solution twice in a row, it detects that nothing has changed and seems to fly through the solution build. Does this mean it knows that nothing was changed in a project and doesn't have to make a new DLL output?
If that's the case, I have a question. Say I have a solution with multiple class libraries, and an MSBuild task in each project that automatically increments the build's version by modifying AssemblyInfo.cs. Thing is (if my previous assumption is correct) it does this every time and triggers a new rebuild of each class library. Is there a target or property in MSBuild that can tell if the project needs recompilation, and skip my versioning step if so?
I ask because let's say I update project A, but not project B in a solution. If I run a build on the solution, I want it to update the version on project A, but since project B hasn't changed, I want to leave it alone.
Found something: http://msdn.microsoft.com/en-us/library/ms171483.aspx
MSBuild can compare the timestamps of
the input files with the timestamps of
the output files and determine whether
to skip, build, or partially rebuild a
target. In the following example, if
any file in the #(CSFile) item
collection is newer than the hello.exe
file, MSBuild will run the target;
otherwise it will be skipped:
<Csc
Sources="#(CSFile)"
OutputAssembly="hello.exe"/> </Target>
...that worked. But then got me thinking, what if someone pulls the code down from source control without the assemblies (which is how we do it)? Since it has no output to compare against, it'll do a compile and increment the version anyway. I think the complexities might lead me to abandon this approach.
It doesn't really matter if you increment on a developers box - what's important is that your daily/CI build is only incremented when needed. So, what I've done in the past is have some small XML file contain the next build number, and have an MSBuild task take this xml file and create a file called Version.cs (containing the versioning attributes you'd usually find in AssemblyInfo.cs).
Version.cs is never checked into your soure control - it's generated by the build.
Developers will sync the current XML file, build their binaries, and get the current version number. The continous integration build may also do the same thing. But a daily/official build will check out the XML file, increment the version information, and then check it in. From that moment on the version number has officially changed.
There are variations on this theme, but the general idea works.