I'm quite new to MVVMCross but I've been actively using it for two weeks, at work and in a school project, and I am really enjoying it! Unfortunately, I've been stuck on the school project for 2 days now : we're asked to do a mobile Jabber client. This is not a big deal since I started it using Matrix XMPP library, which does most of the job and is easy to use. I decided to restart my project using MVVMCross, in order to have cleaner separated code and add a Windows Phone project, but Matrix absolutely needs System.Xml.Linq, and I can't get the core PCL to compile :
The type 'System.Xml.Linq.XElement' is defined in an assembly that is not referenced.
You must add a reference to assembly 'System.Xml.Linq, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
As shown in Stuart Lodge's tutorial videos, I'm using profile 104, the the faulting dll is really present in the folder, I can't add it manually to project's references since VS prevents me from doing it (gently explaining that it's automatically loaded since .Net portable subset is included in references), I've updated and repaired my VS install "just in case"... and have no more idea left.
So, here are the questions :
is it really possible to use System.Xml.Linq with MVVMCross? or did I miss the big title explaining that what I'm trying to do is stupid?
if yes (that'd be great!) did/does someone experience the same problem? Even more interesting : did someone find a solution?
Thanks in advance!
Additional info : Windows8(x64), VS2012 Ultimate, trial license (school project...) for Xamarin.Android
UPDATE : following Stuart's answer, I compiled and ran the BestSellers sample, which uses System.Xml.Linq... without any problem. As it comes with an explicit reference to System.Xml.Linq (see first link in answer), I tried :
to delete it (and a few others) : VS holds it's promises, and really includes needed references as long as .Net Portable Subset is referenced, so everything rolls smooth.
to manually add this reference via Notepad to my .csproj : it doesn't change anything.
One thing tickles me in Stuart's answer : "perhaps it is something to do with the way the matrix uses XML.linq". Since the Matrix type I'm trying to use is just a descendant of System.Xml.Linq.XElement, which is widely used in BookViewModel.cs from sample, what could possibly be wrong with that?
"Solution" : The problem seems to be due to Matrix requiring a special version of System.Xml.Linq, which is not the one included when profile 104 for building PCL. I used file linking method as a workaround to share the core, and that works, though this is less elegant, readable, and harder to maintain...
Yes it is possible to use at least some of System.Xml.Linq
For example, see the BestSellers sample
csproj file - https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20BestSellers/BestSellers/BestSellers/BestSellers.csproj#L49
example XML linq use - https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20BestSellers/BestSellers/BestSellers/ViewModels/BookViewModel.cs#L44
For the problem you are seeing, I'm really not sure what the error is - perhaps it is something to do with the way the matrix uses XML.linq? You might have more luck of you open up this question to other tags like portable-class-library, XML-linq and windows-phone.
Related
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
I am using Delphi XE6 and using Datasnap and JSON in my project. There is a bug I want to correct in the VCL unit System.JSON.pas (in the TJSONString.ToString function) where it should be escaping backslash characters as well as quotes. In order to fix this I carried out the following :
Copied System.JSON.pas from the standard VCL source folder to my project source folder
Added System.JSON.pas to my project (using the newly copied file)
Fixed the bug and attempted to compile
I get the error 'Unit Data.DBXCommon was compiled with a different version of System.JSON.TJSONObject'
I can see that the Data.DBXCommon unit references System.JSON, so I guess the compiler is now seeing 2 versions - my fixed version and the standard VCL version.
What is the correct way to implement VCL changes to avoid this problem?
There are two common reasons for this issue:
You made changes to the interface section of the unit. You cannot do this without also re-compiling all units that use the unit you are modifying.
You re-compile the unit with different compiler options from those used to build it originally. Deal with that by ensuring the compiler options used to compile the unit you modify are the same as used by Embarcadero. Typically Embarcadero compiles with default options. Impose these directly in the source file being modified, right at the very top of the file.
Having said this, a recent question here on a similar topic could not be resolved using option 2 above. In that question, under XE6 only, the unmodified Classes unit could not be re-compiled and linked at all. Which makes me wonder if this particular technique has had its day. Perhaps it's not even possible. Before you give up, see if you can compile and link the unmodified unit.
More broadly, using a detour is generally an easier way to solve such problems as you face. Using a detour rather than re-compiling makes the management of the fix cleaner and simpler.
Update 1
I cannot get the unmodified System.JSON unit to re-compile and link. Which I think means that the issue raised in that other question is broader than just the Classes unit. I think you will find this a tricky hurdle to overcome and recommend the use of a detour.
Update 2
The problem that appears to have been introduced in XE6, seems to have been resolved by the release of XE7. The unmodified System.JSON unit will compile and link in XE7.
What if Delphi XE6 original System.JSON.dcu wasn't compiled with Delphi XE6 but it was compiled with one of the previous versions of Delphi.
You claim that you managed to implement your fix in Delphi XE2 using same approach by changing source and then recompiling System.JSON. SO I suggest you first make a comparison between original System.JSON files that ship with both Delphi XE2 and Delphi XE6.
If they are the same then the changed System.JSON.dcu that you managed to recompile with Delphi XE2 might also work with Delphi XE6.
I resolved a similar issue by :
Deleting the .dcu files which are on different versions ( i.e. conflicting files).
Re-build the project to create new .dcu files.
Cocos2d-x 3.0 alpha was released for some time now. What was improved over cocos2dx-2?
The features list is quite important, but in terms of performance are there new limitations/improvements?
Have you noticed real improvements in performance, development patterns, APIs and support?
I've been using it recently and from what I've noticed the main differences are that everything is namespaced now, so you don't have to deal with the prefixed names that came from the objective c patterns, so cocos2d::Point instead of CCPoint (especially for enums, (Texture2D::PixelFormat::RGBA8888 instead of kCCTexture2DPixelFormat_RGBA8888)).
Also some of the event stuff now has support for c++11 lambdas.
A more complete list of the changes can be found here: http://www.cocos2d-x.org/wiki/Release_Notes_for_Cocos2d-x_v300
but for the most part of using it myself, it's just made to feel more like C++, instead of like objective-c.
I have switched and am finding it pretty stable. The main advantages so far ...
Real buttons, instead of menus
Real-time spritesheets
SpriteBatchNodes are no longer recommended and I did see a drop in draw calls where I not optimized
less objective C patterns.
more modern. namespaced instead of 'CC'. C++11.
more platforms supported
Main disadvantages for me:
EventListener pattern. I can't figure out how to get touch input to affect any objects other than the Node that triggered the event.
We use a lot of text-only buttons for debugging and they are hard to lay out :)
Lack of documentation and example code. For example, I could not find any documentation of how to use the Layout class anywhere.
It is a lot of work porting, but for us we had to decided to risk it since we would end up maintaining an out-of-date code base. It took about 5 person-days to port our game over. The game is now stable and we did not run into a single bug in cocos.
I think its C++11
auto
lambda
And it has no unnecessary use of prefix CC
One of the changes that happened between Cocos2d-x 2.1.5 and 2.2 was the removal of templates for projects in XCode (I do not know if project templates existed in VS, etc).
The new build system creates projects under the Cocos2d-x installation (at least on Mac) and that is where the project files appear to reference them. This makes it very difficult to move the project without hand tweaking. It also makes configuration management more painful, depending on how you set up your system (e.g. a root/tree like svn or a "drop it anywhere" like git).
Also, the Cocos2d-x library is built as that, a library. In previous incarnations, it was placed directly into the project. On one hand, if you don't alter the root library code, this makes good sense. On the other hand, if you occasionally tweak things for a specific project, you have altered all your projects that depend on it. Yin/Yang.
I'm still very positive on Cocos2d-x. I have not upgraded to 3.0 or 2.2 yet. When it matures a little more, I will switch over, regardless the changes. For what I need, I'm pretty sure it will still get the job done (well).
We have a group of developers moving from C++ to C# and WinRT. We used D'Oxygen as part of our C++ developer builds, and I'd like to continue to have document generation as part of the developer build in C#/WinRT.
It's easy to turn on XML Doc generation, and I believe that will provide warnings for malformed tags, but without actual HTML output, I think our developers will be missing valuable feedback.
Looks like NDoc is now defunct, and I took a quick look at Sandcastle, but found it rather complex. Ideally, I'm looking for something that doesn't unduly burden developers, or require them to remember extra steps as they edit, build, test, and commit. In other words, the best solution would be something that "just happens", like a post-build step, and doesn't add significantly to each developer's build time.
If anyone has had some experience doing this in C#/WinRT, I'd sure like some advice.
Thanks in advance!
Get Sandcastle Help File Builder.
Create a help project for your library in the Visual Studio solution.
Remove Build check mark from Debug solution configuration to build the documentation project only in Release configurations, since Debug is most often used during development. For release build testing or performance testing you can either create another solution configuration or simply switch the option back and forth.
Build the documentation once
Include the documentation file in the solution so it shows up in the Pending Changes window when the file changes.
Kindly ask your developers to build with the release configuration that updates the documentation before check-in or use any other policy to require updating the documentation.
I don't think it makes sense to build the documentation all the time, but it helps to make it easy to do so that when you actually need an updated version - you can build it really quickly.
You can also make sure to use FXCop or StyleCop (forgot which) and configure it to treat missing XML documentation warnings as errors - at least in release builds. Doing it for debug configurations might slow down development and make changes difficult since developers often want to try things out before committing to a final implementation worth documenting.
EDIT*
Sandcastle provides various output formats as shown in the project properties:
I would like to mention ForgeDoc (of which I'm the developer), it could be what you are looking for. It is designed to be fast and simple, and it generates proper MSDN-like HTML output. It also has a command-line interface so you can just call it from a post-build event command in Visual Studio.
I think you should give it a try, as I would really like to hear about your thoughts.
I spent this morning in trying to figure out where the system.linq.expressions namespace is. The following is what I did:
In VS 2008, Create a new C#/Smart Device/Windows Mobile 6 Professional SDK/.NET CF v3.5/Class Library
Used SqlMetal (in Program Files/Microsoft SDKs/Windows/v6.0A/Bin) to generate the data context.
Added the data context .cs file into the project.
Compile and many errors for missing namespaces: System.Data.Linq, System.Data.Linq.Mapping, System.Linq.Expressions
After some research added System.Data.Linq.dll in c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5 (The dll was not directly listed when I choose to add reference and I used "browse" tab to finally located the one, which is for normal framework)
Compile again, less errors, but still System.Linq.Expressions namespace is missing.
The document says System.Linq.Expressions is in System.Core.dll but it seems my System.Core.dll (located in Program Files\Microsoft.NET\SDK\CompactFramework\v3.5\WindowsCE) contains much less namespace than document says.
Thanks in advance!
The Compact Framework does not support LINQ to SQL. All objects in the documentation for System.Data.Linq confirms this by being completely devoid of the "supported in the CF" icon. For example, look over at the docs for DataTable, which is supported. You'll see a little icon by each supported method/property.
You cannot "add" support by simply referencing a desktop assembly like you did in your step 5. The CF cannot consume full framework assemblies, for a variety of reasons.
Dynamic code generation (Reflection.Emit) is not available in NETCF. What this means is that a lot of features that depend on this is not available, this includes DLR (dyanmic language runtime and hence languages like IronRuby), Linq-to-SQL/
If you just want the Linq.Expressions and you are doing your own stuff with it i.e. not trying to get linq to sql working then you can use the System.Linq.Expression stuff from the db4o guys.
I am using it on my project using linq to objects.
db4o linq implementation