In the project file of my .NET MAUI app, I see a section that contains MSBuild:Compile directives for each and every view in my app -- see below:
<ItemGroup>
<MauiXaml Update="Views\Home\Home.xaml">
<Generator>MSBuild:Compile</Generator>
</MauiXaml>
<MauiXaml Update="Views\Home\Page2.xaml">
<Generator>MSBuild:Compile</Generator>
</MauiXaml>
<MauiXaml Update="Views\Settings\Settings.xaml">
<Generator>MSBuild:Compile</Generator>
</MauiXaml>
</ItemGroup>
What exactly is the purpose of this section and is it necessary? It looks like they're instructing the views to be compiled but are they necessary? Would they not get compiled without these directives?
Ultimately all XAML needs to be compiled. When it happens matters. It can either be pre-compiled at design time or build time, or compiled at runtime. Obviously if compilation happens at runtime, it can slow the app down due to the time it takes to compile the XAML so generally pre-compiling XAML is preferred.
The <Generator>MSBuild:Compile</Generator> tells MSBuild to generate the C# for the XAML page every time the XAML file is saved, saving time to do the same during project build. The IDE does insert it by default because the engineering team feel it is beneficial to most as it will reduce build time when debugging. You are of course free to remove the elements if you do not want that behavior.
Hope it works for you.
Related
I'm developing a struts2 webapp for months now using maven to manage my dependencies and I've just discovered LESS. I have installed and configured the LESS plug-in for Eclipse but it's really annoying to right click > run as > LESS compiler every time I save the .less file due to a modification of its content or something...
The thing is that I've been researching on how to plug in grunt.js (recently discovered task runners too) into maven (as explained here) but I think it's quite hard and I wondered if somebody knew an alternative to this.
In my struts2 project I have both the front and back-end of my webapp.I know it's not the right approach and if I could start all over again I would separate them into two different projects, but now it's too late (disadvantages of the learning proccess, we're not born knowing it all).
Having said all this, how can I set up a kind of task for watching my .less files and automatically compile them into .css when saved/changed?
I also found this ant task here, but I dont really know if it's what I'm looking for.
There are a lot of Java Less compiler (see Java Compiler for Less CSS?), so you can execute one of them by your build tool (e.g. Ant - maybe you need to write a simple Java application, which use the chosen compiler).
If you use Maven (or can switch to it) to project management, then you can use one of lesscss-maven-plugin:
biz.gabrys.maven.plugins:lesscss-maven-plugin
org.lesscss:lesscss-maven-plugin
see more...
It is possible to create an ant task to compile certain .less files into CSS whenever they are modified, and more or less is what I was looking for, but grunt seems to be more flexible as you can tell it to watch all your files with .less extension and in this solution I've found you have to declare in an .xml file the .less files you want ant to watch.
This is not explicitly what I was looking for so I'll leave this question open for now as I'll keep researching on how to make this solution more dynamic and see if it is possible to avoid the fact of defining every .less source and .css target you want.
Link to solution here
I'm currently working on a project which source code should be as portable as possible; that is, the project (in C#, but it is not very relevant) represent an application that should be executed on Android (with Mono-Android), on iPhone (with MonoTouch) and WinMobile (with official Compact Framework). Without going into details, the corresponding MSBuild solution consists of an independent-platform library (from a source code point of view, at least) which declare various interfaces and classes that represent an abstraction of each feature that is not common to the various platform (i.e. the UI). In addition, there are a corresponding library that specialize (for each platform) the "base library"; the effective application executable is a program that uses the abstraction and the common standard libraries.
Developing on WinMobile and Android is not really a problem: Mono-Android add-in can be installed on VS 2010, so both platforms can be handled with MS VS.
Initially the solution was created in VS, so the initial configuration and the related projects (Android and WinMobile) are automatically generated.
After that I've imported the solution in MonoDevelop under Mac (the only platform that is officially supported by MonoTouch), and I've created the project for the iPhone library; switching the configuration to generate the assemblies (iPhoneSimulator) the "base library" was not possible to compile due to a missing project type configuration; specifically, the GUID used by MonoTouch for <ProjectTypeGuids> is {E613F3A2-FE9C-494F-B74E-F63BCB86FEA6}; adding this GUID I can now compile "base library" in MonoDevelop.
The problem arises when I try to re-import the solution in VS: since there's no Windows version of MonoTouch, VS cannot find the add-in for the specified project type, and the project doesn't load.
Looking to the specifications of MSBuild project file, it seems that there are tons of options that cannot be set or modified within the project/solution editor in VS; however the format is quite complicated and now I'm asking your help!
Is there a way to specify in the project file that a project type is present only if a particular configuration is selected independently to which is the environment I'm using?
The general approach is something like this; a condition that progressivly builds your property, referencing any value the property already may have:
<ProjectTypeGuids
Condition="'$(BuildingInsideVisualStudio)' != 'true'"
>;{E613F3A2-FE9C-494F-B74E-F63BCB86FEA6}"</ProjectTypeGuids>
<ProjectTypeGuids>{OTHER-GUIDS-HERE}$(ProjectTypeGuids)</ProjectTypeGuids>
This will detect the VS condition (when building) and omit the unkonwn guid. I'm not sure however if it will work when the project is opened, this property might only apply to building. There may be a similar "sentinal" property for building on Mono, and you can reverse the condition.
I solved an unrelated, but very similar issue of cross-platform development by excluding the files that presented themselves as cranky when going between Linux and Windows. I have my project under source control and utilized that to keep things working cooperatively.
http://www.aydabtudev.com/2011/05/what-goes-into-source-control-android.html
It's not a 1-to-1 for your issue, but it might give you clues/ideas on how to solve your problem.
we all agree that when we use GWT, we compile our application on the server, several javascript file are created. Normally, when deploying, we would use the obfuscated mode.
Now modifying a javascript file in obfuscated mode is almost impossible. Now what happens if we want to make some modification in our GWT application.
Do we have to go back again in Java, modify the file, compile, and then deploy again??
I'd say yes... If you use a code generator you should avoid modifying the generated code by hand.
No, no, no.
You don't "go back" to the Java code to modify it. You simply debug, test and modify the Java code. You ignore the code in the compiled javascript files except to deploy it. As far as you are concerned, GWT source code is Java code, not javascript, written within the environmental restriction of the browser.
Your question is like asking, "I have a C application that gets compiled to object code. Do I modify the object code or go back to the C code to modify it?" !!!
You simply treat the generated javascript as "native code".
No doubt you can include javascript using jsni, and so can you include assembly code when using C. So except for those assembly code you inject and similarly except the javascript code you include, you leave the "native code" alone.
When you try to modify the object code generated from C, that is called hacking. Hacking is an interesting hobby but when you wish to create an application and your main task is not "hacking", hacking would only be your extra-curricular activity not connected to your main employment or project.
Go back to the beginning: http://code.google.com/webtoolkit/overview.html
...Write AJAX applications in Java and
then compile the source to highly
optimized JavaScript that runs across
all browsers
When you're ready to deploy, GWT
compiles your Java source code into
optimized, stand-alone JavaScript
files that automatically run on all
major browsers, as well as mobile
browsers for Android and the iPhone.
While debugging: if you are running in development mode you may not even have to redeploy while in dev.
Thanks to the GWT developer plugin,
there's no compiling of code to
JavaScript to view it in the browser.
You can use the same edit-refresh-view
cycle you're used to with JavaScript...
I was always wondering what's up with those Targets? What is it all about? What's the point of that? I never had to fiddle around with them, but obviously I can. Why should I want that, and what can I do with them? What's their purpose?
Each project can build multiple executables or libraries or call out to a makefile or shell script to build "stuff". Each one of these is a Target.
One iPhone project I have includes a separate target for each static library in my home grown SDK and a shell script target to build the Doxygen docs. Another project includes two targets, one for the app as used by general users, one for an administration & management edition.
In the first example, I need to build each library then link all the static libraries into an SDK test application, so my SDK Test App depends on all the library targets (but not the docs, since I don't need to constantly regen them.)
In the second example, the management and the general versions of the app share a considerable amount of code and resources. When I change one, I want to change them both.
The target is something like a "blueprint". It includes rules that tell the compiler what to do, which sources should be compiled, which files should be copied into the application bundle, which libraries should be linked.
If you want to make a Free-Version of your app one way to do so is to add a new target.
Of course you could just duplicate the whole project but then you had to keep those in sync if you change some code. Using a different targets makes this a lot easier.
I've looked at Microsoft's MSDN and all around the web, but I still haven't been able to get a really good idea of what it is.
Does it mean the completed program loads DLLs at different times during its execution, as apposed to all at once upon launch?
Am I totally way off? :)
Linking involves packaging together all of the .obj files built from your source files, as well as any .lib files you reference, into your output (eg .exe or .dll).
Without incremental linking, this has to be done from scratch each time.
Incremental linking links your exe/dll in a way which makes it easier for the linker to update the existing exe/dll when you make a small change and re-compile.
So, incremental linking just makes it faster to compile and link your project.
The only runtime effect it might have is that it may make your exe/dll slightly bigger and slower, as decribed here:
http://msdn.microsoft.com/en-us/library/4khtbfyf.aspx
Edit: As mentioned by Logan, incremental linking is also incompatible with link time code generation - therefore losing a possible performance optimization.
You may want to use incremental linking for debug builds to speed development, but disable it for release builds to improve runtime performance.
Delay loaded DLLs may be what you are thinking of:
http://msdn.microsoft.com/en-us/library/151kt790.aspx
Also, quite importantly, incremental link is a prerequisite for Edit&Continue - possibily to edit your code and recompile it on the fly, without restarting.
So it is a good thing to have on debug builds, but not release builds.