I have an API that inherits flash.display.Sprite .When I try to generate the ASDocs for the API, The ASdoc shows that my class inherits from flash.display.Sprite, but doesnt link or there is no click-able link to the Sprite's ASDoc. Can anyone tell me what I am missing.
The command I am using in my ant script is
<java jar="${asdoc.jar}" dir="${FlexSDK.dir}/frameworks" fork="true" maxmemory="256m" failonerror="true">
<arg line='-load-config "${flex-config.xml}"'/>
<arg line='-source-path ${src.dir}'/>
<arg line='-doc-sources ${src.dir}/com'/>
<arg line='-output ${docs.dir}'/>
<arg value='-library-path+=${FlexSDK.dir}/frameworks'/>
Thanks in advance for your help.
ASDoc generates documentation for your classes, not for the Flash's default classes.
You can include the Flash and Flex docs as long as you have access to them locally to your build. By default they aren't included, but if you have access you just need to include another library path. See this post for more details:
http://unitedmindset.com/jonbcampos/2010/01/28/building-asdocs-with-ant/
Short:
Not possible because we don't have access to the commented source for flash.*.
Long:
AFAICT, ASDoc works from source, and source only. While the Flex framework classes are open source, the core Flash framework classes are not. They are delivered as a binary in the Flex SDK: [flex_sdk]/frameworks/libs/player/10.1/playerglobal.swc. You can unzip this, but it just contains the catalog.xml and binary library.swf.
Related query:
http://www.ultrashock.com/forum/viewthread/87106/
(Note to others looking to include the Flex SDK classes in their ASDocs: see [flex_sdk]/asdoc/build.xml to get a jump start configuring asdoc.)
Related
I'm using a package Xamanimation which has a dependency of Xamarin.Forms 4.1.0( written in its nuspec file):
<dependencies>
<group targetFramework=".NETStandard2.0">
<dependency id="Xamarin.Forms" version="4.1.0.581479" exclude="Build,Analyzers" />
</group>
</dependencies>
but I have built the Xamarin.Froms for my own and added the output dll files into my project's reference:
<Reference Include="Xamarin.Forms.Xaml">
<HintPath>..\thirdparty\xforms\Xamarin.Forms.Xaml.dll</HintPath>
</Reference>
according to the nuget's doc, I add the ExcludeAssets attribute(and other tests) to the section of PackageReference of Xamanimation:
<PackageReference Include="Xamanimation">
<IncludeAssets>compile</IncludeAssets>
<!-- <ExcludeAssets>compile</ExcludeAssets> -->
<!-- <PrivateAssets>all</PrivateAssets> -->
<!-- <ExcludeAssets>buildtransitive</ExcludeAssets> -->
<Version>1.3.0</Version>
</PackageReference>
but none of them work!
MSBuild will always use the trasitive dependency Xamarin.Forms.4.1.0 and ignore my own build ones( in which I have add new classes and use them in the main project so the linking failure is indicating the choosen is the old one).
so what's the correct method to exclude the transitive dependency?
I spend a whole day learning into this question and finally got a reasonable answer.
so I'd like to post my first LONG answer in stackoverflow by my poor english.
TL'DR:
the MSBuild's nuget plugin's ResolveNuGetPackageAssets target do the evil thing, make a custom target to revert it, go to bottom for the task code.
Studying story
first, I made a similar but simpler copy of this problem for studying.
after all, building a xamarin project is too slow,
the demo source is in github,
it has four project:
ConflictLib: the library used both by another lib and main application
DirectLib: the library used by main application, and is using ConflictLib
MyAppDev: the main application, with above two library as ProjectReference
MyAppConsumer: the other application, using DirectLib by PackageReference, and ConflictLib as ProjectReference. to test this situation, I pushed the ConflictLib and DirectLib to nuget.org, then made modify to local version of ConflictLib, so I can verify which one is using.
these projects and their relationship are very similar to my origin problem, the key point is : when application use a library with two different version simutanously, will(should) the local one(ProjectReference or HintPath) win?
for my origin case, xamarin project, it's No, so I come to study it.
for the test case, a dotnet core console project, it's Yes, so there must be something mysterious in the building process: MSBuild, which is a huge system, but now I'm going to dig into it.
then, I need a inspecting tool to find out what MSBuild does when building a project.
the simple tool is just invoke it in command line, it will display all the targets executed. a msbuild target is something like a target in makefile, and the tasks in target are similar to commands in makefile, the concept exist with slightly different term in many other system such as gradle, so it's easy to understand.
but, there are so many targets and tasks, and all they depend on others and interactive though Property and Items, it's hard to learn which target break my need from the text log.
fortunately, there's an advanced tool for inspecting everything in MSBuild: it's called MSBuild structured log viewer, I learn it from here.
now build the project with /bl option, it will produce a binary log file with full info, open it by the viewer mentioned above:(my origin xamarin project's build log)
obvious, the ResolveNuGetPackageAssets target changes the Reference items, which decides the final linked library assembly.
but why it doesn't make the wrong decision in the test case? let's view its log:
got the difference? -- there's no ResolveNuGetPackageAssets target!
it's same from ResolveReferences to ResolveAssemblyReferences, but diff in the nuget part.
while double clicking at ResolveAssemblyReferences, the viewer will open the targets file in which the target be defined.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets
it's still same for both case:
ResolveAssemblyReferences doesn't depend on ResolveNuGetPackageAssets, so where does the later come? just click at it, the file opens:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\NuGet\16.0\Microsoft.NuGet.targets
it overrides ResolveAssemblyReferencesDependsOn and add the ResolveNuGetPackageAssets to dependency of ResolveAssemblyReferences.
the last question: why the above NuGet.targets file not appear in the test case? it could still answered by the viewer's Evaluation section:
clearly, this file is not imported because a property SkipImportNuGetBuildTargets set to true. after a simple search, I confirmed it's the default value in test case: it's set in Microsoft.NET.Sdk.targets. but in xamarin case, it's not set and means false, so all the things happened.
finally, I have to figure out some measures to fix the problem.
first of all, I won't add the SkipImportNuGetBuildTargets property to xamarin project, because I think it's a framework design and maybe has a great impact on others, I just want to fix a little, specific problem.
I decide to add a custom target immediately after the ResolveAssemblyReferences, remove the Nuget's Xamarin.Forms and add my own ones -- just revert what ResolveNuGetPackageAssets does.
the task code is simple (only just after I have written, actually it cost me lot of time to search for grammar/builtin function/etc and test):
notice how the Remove Item(see msbuild doc) works (and not work: the commented lines), I still don't understand it exactly, but it did work!
In Apache Karaf, before I install my features.xml file I need to type.
feature:repo-add camel 2.17.3
Is there any way to express in the features.xml file some command which makes this occur ? So that I can avoid typing it on the command line inside Karaf.
The motivation for this question is that it is nice that generally when I add a features.xml file to the deploy directory of Karaf that it can pull down all the dependent bundles by itself automatically. I like the fact that it has this automatic feature and the only thing I need to send is the features.xml. So this leads to my desire to encapsulate all the work in the features.xml file so that I do not need to type anything into the Karaf console.
This works. You need to refer to the camel feature xml using the repository tag.
See the cxf-dosgi samples feature xml.
The repository xml tag must appear within the features XML tag. So its like:
<?xml version="1.0" encoding="UTF-8"?>
<features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0" name="jump_micro">
<repository>mvn:org.apache.camel.karaf/apache-camel/2.17.3/xml/features</repository>
<feature description="jump_micro" version="1.0.0" name="jump_micro">
...
This is a shortcut for feature:repo-add mvn:org.apache.camel.karaf/apache-camel/2.17.3/xml/features
so no, this can't really be skipped as you somehow need to tell which feature file to use. If you skip the version it'll be that latest available version.
We've got a Windows 8.1 app that we've converted to a Windows 10 UWP app. The app works fine in debug, but when running in Release (.Net Native), we are getting a runtime error on app load. It's not at all clear what's causing the error. The error happens in the OnLaunched event in App.xaml.cs where some data is being initialized. The error:
An exception of type System.NullReferenceException occurred in
System.Private.CoreLib.dll
Additional information: Arg_NullReferenceException
We're using the latest versions of MVVM Light.
I know this isn't a lot of info, but it's really all we have right now and are pretty stumped. Anyone seen and issue like this or know where to start in tracking it down?
If, you're still using SQLite or any Reference.
Please Right Click to your Project => Add => Reference => Make sure your DLL of Nuget is checked.
Please Check this solution.
I had this exact problem in that I converted an 8.1 app to UWP. This was resolved by including a file called Default.rd.xml in the Properties folder. This was not mentioned in the migration guide that I had used.
Not including it means some pretty common coding patterns such as reflection will not work, and this includes in imported .dll's.
A basic Default.rd.xml file looks like the following ...
<!--
This file contains Runtime Directives used by .NET Native. The defaults here are suitable for most
developers. However, you can modify these parameters to modify the behavior of the .NET Native
optimizer.
Runtime Directives are documented at https://go.microsoft.com/fwlink/?LinkID=391919
To fully enable reflection for App1.MyClass and all of its public/private members
<Type Name="App1.MyClass" Dynamic="Required All"/>
To enable dynamic creation of the specific instantiation of AppClass<T> over System.Int32
<TypeInstantiation Name="App1.AppClass" Arguments="System.Int32" Activate="Required Public" />
Using the Namespace directive to apply reflection policy to all the types in a particular namespace
<Namespace Name="DataClasses.ViewModels" Serialize="All" />
-->
<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
<Application>
<!--
An Assembly element with Name="*Application*" applies to all assemblies in
the application package. The asterisks are not wildcards.
-->
<Assembly Name="*Application*" Dynamic="Required All" />
<!-- Add your application specific runtime directives here. -->
</Application>
</Directives>
If this does not work, then try creating a new empty UWP project to get the latest format for the file.
In the simplest of Flex Projects, create an MXML Flex Module and then load it using the ModuleManager. No problem. Create an ActionScript class that extends Module and then configure your project to compile that into a Module. Load this new module instead. The project compiles, but crashes when running with the following error:
"Error: Could not find compiled resource bundle 'containers' for locale 'en_US'."
I believe the compiler is failing to compile the required class definitions into ActionScript only module, while it succeeds for the MXML module. I can see that my skeleton MXML module is slightly larger than my ActionScript module (66KB vs. 45KB).
How can I resolve this problem (if that is indeed the issue)?
A good approach in these sort of situations is to use -keep-generated-actionscript for two projects, one with the mxml approach, and one with the actionscript approach. You can then compare the code to see what might be missing from one project, but included in another.
Have you tried adding an explicit reference to [ResourceBundle("containers")] to your ActionScript project class? The mxmlc is different to the compc compiler in behaviour for many valid reasons.
I was having this same problem when compiling a library swc. I was able to fix it by adding the following section to the projects projectName-config.xml
<include-libraries append="true">
<library>${flexlib}/locale/{locale}/framework_rb.swc</library>
</include-libraries>
This forces the compiler to include the framework resource bundle for the specified locale.
for me the issue was finding out which project - in my case a library - and which class in this library caused this behavior (I needed to realize my last changes - no info from flashbuilder). Then applying the following attribute to the class:
[ResourceBundle("containers")]
public class IpChecker {
...
That did the trick.
My Cairngorm program does some preliminary authentication against a RemoteObject before allowing Cairngorm's ServiceLocator to start using the same RemoteObject to get business data. Everything works fine with Flex Builder, but I need an Ant build. The Ant mxmlc task compiles everything ok, but at runtime the resulting code fails at the getService() method on Cairngorm's RemoteObjects class, because it can't find the service.
Might this perhaps be due to the Cairngorm code being differently linked in the Ant-driven compilation? In the file resulting from -dump-config (and this file is fine, used with mxmlc on the command line) the only reference to the Cairngorm swc is in this element:
<library-path>
<path-element>\path\to\directory\containing\Cairngorm.swc</path-element>
</library-path>
The corresponding element in my build.xml is
<compiler.library-path dir="${basedir}" append="true">
<include name="libs"/>
</compiler.library-path>
I can't see anything that would affect how Cairngorm is linked, apart from an explicit setting of static-link-runtime-shared-libraries to true in both the FB output and in my build.xml. Perhaps my linking theory is all wrong? But what else could be making Cairngorm's remote access fail when access from elsewhere in the same SWF to the same RemoteObject has been ok?
It sounds like the ANT build might be missing the -services flag to compile in the services-config.xml file that configures the RemoteObject endpoints.
In FlexBuilder, look at the project properties and navigate to the Flex Compiler pane. You should see an "Additional Compiler Arguments" field. Make sure that these same additional arguments are passed to the ANT compile task. You're looking for something like "-services services-config.xml"