Is it possible in monodroid to have Drawables, Layouts, etc... (I mean resources) in a DLL? The problem is that I have created a project that generates a DLL but it doesn't build the project structure a regular android application project builds. Is there any possibility to accomplish this? Where should I move drawables, etc... in a dll?
This is not supported in the current version of Mono for Android. This post on the mailing list provides some more details about it. It's on the roadmap to get added in a future version, but I don't think they've given a timeline on it.
Related
VS2013, MVC5, VB
I am nearing the completion of a small project to manage the roles tables in a standard MVC5 application. The code is pretty much encapsulated. What are my options for using this 'package' in other projects?
Can I compile it into something? I know this type of action is possible, I'm just not familiar with the options available to me or the steps to do this. Links to sites that have tutorials are fine. Is creating a Nu Get package the only way to go, or is that even in the ballpark of what I'm asking. I say Nu Get, but I don't mean for public consumption, only for my consumption.
Will the finished 'whatever' include it's controller class, view models and views? Will I be able to easily manage updates? etc.
Creating a Nuget package is one way. I have created a local repository of common utilities for this purpose. But I usually use it just for DLLs. I use Nuget Package Explorer for its ease of use since its just me using the packages most of the time. Not sure its possible to place the files in specific directories.
Files in the content folder are copied to the root of your application when the package is installed. - Nuget
The alternative is to create an item template. I used to use this method for class files I want in my code but I can't see why you couldn't do it for the rest. Works well and isn't too hard to set up. There are dozens if not 100s of tutorials on the subject. Here is one on code project.
Let's say we have a team that works on many different projects. Each team member uses different set of visual/non-visual controls/components during it's development cycle. Since Delphi requires each component to be compiled and installed globally in the IDE, how to manage this situation while working with project which was started by the other team member?
It would be great if I could checkout the sources of a project from the version control and have the ability to compile it immediately. I don't care or sometimes don't know what visual or non-visual components are required for this project, I guess they all should be included in the project sources.
Maybe there are some tools which could read main project file or directory and compile/install all the needed components on project loading (and uninstall them when project is closed)?
How do you handle this issue in Delphi?
In our company, we have the same problem.
We solve this by forcing everyone to have all necessary library paths added to their delphi ide.
We are using an additional sdk/framwork repository which containins all components/sdks/frameworks of everyone .
We keep a single text file, listing all libs with its version, install infos, etc.
Everyone checks their wanted libraries, so we do not have double libraries or different versions.
Since we all work under Windows and since Delphi keeps its paths and (afaik) installed-components informations in the registry, we extracted these informations.
We store for each used delphi version a .reg file within the sdk repository trunk.
So, if someone changes a framework, he updates the informations for everyone in the .reg files and commits it.
now, if someone wants to setup their dev-machine, they check-out the sdk, adds the e.g. xe2.reg informations to their registry, then check out the project and ... tada. compiling.
We have not tried to extract the "installed components" packages. thats on our to-do list.
An alternative would be to keep a batch file for building and installing all sdk packages at once. But i do not know if installing components via commandline is possible in delphi.
Something like the JEDI installer would be nice. The installer detects installed Delphi versions and builds & installs everything nicely.
A freely configurable version would be nice, so add all sdks -> install on each version.. perfect.
Anyone who wants to compile a given project must first install any components that project is using. There is no getting around that, unless the project directly includes the components source code and instantiates the components in code instead of using a DFM. AFAIK, there is no IDE tool that will automated component (un)installation on a per-project basis for you.
It's very wise to constraint which components and libraries that will be used by your team. If each member decide which component they will use, your final executable or packages will grow a lot and you can have some incompatibilities between libraries.
Besides, you can have extra costs buying and updating libraries that are very similar. Remember that each time Delphi is updated, you should buy new licences from most of that libraries.
So the best approach is:
ask which libraries each developer are using and discuss with them the real need of each one;
catalog those library required and install them on the machine that you will compile your final code;
I recently updated to Visual Studio 2012 Ultimate. I was programming previously with DirectX 11 June 2010 SDK and want to continue to do so using Visual Studio 2012. However, I discovered that VS2012 comes with its own DirectX SDK (in Windows Kit 8.0) and I've been trying to migrate my code using the newer versions of d3d11. Everything went fine until I try to use effect files in my project (.fx files). I had to compile the Effects11 Sample in the DirectX SDK using VS2012 and link the lib file in my project. That went fine too. However, when I compile my project the function D3DX11CreateEffectFromMemory returns a E_NOINTERFACE error (no such interface is supported). Can anyone tell me why is that? Note that I'm using the d3d11.lib from the Windows Kit and the d3dx11.lib from the DirectX SDK. Perhaps I shouldn't mix them? However, everything else works fine when I mix them, except for the effect file creation.
Any help would be appreciated.
P.S. I don't know if this is helpful but just so you know, if I add an additional library directory in the project settings of "DirectXSDKInstallPath\lib\x86\" it works. Why is that? Does it mean I'm using the older version of the libraries? This will give a ton of warnings about redefined headers in winerror.h
D3DX Library has been deprecated for the newest version of DirectX 11 (Windows 8). See http://msdn.microsoft.com/en-us/library/windows/desktop/bb172965(v=vs.85).aspx
Effects are now handled a different way. You can program your own library to load effects or use DirectX Tool Kit (DirectXTK): http://directxtk.codeplex.com/
Microsoft has recommended this tool kit on their web site, see http://msdn.microsoft.com/en-us/library/windows/desktop/ee663275.aspx for more information.
Effect11 has moved to https://fx11.codeplex.com/, you need to compile it and link yourself.
DirectXTK does not provide the effect11 interface, but only simplified effects
This is probably caused by d3d library conflicts.
Make sure what d3d libraries you are using.Because there are 2 different d3d libraries.
One in DXSDK_DIR\Lib\x86 or \x64,and one in c:\program files(x86?)\Microsoft SDKs.
If you are using DXSDK, then pass $(DXSDK_DIR)Include $(DXSDK_DIR)Lib\x86 ahead of Microsoft SDKs' includes,libs directory in the Include directories and Library directories fields respectively.
In the previous version of Direct3D, the effects framework worked out of the box once you linked with the D3D10 library. In Direct3D 11, the effects framework has been moved to the D3DX library, and you have to include a separate header file (d3dx11Effect.h) and link with a separate library (D3DX11Effects.libfor release builds and D3DX11EffectsD.libfor debug builds).
Furthermore, in Direct3D 11, they give you the full source code for the effects library code (DirectX SDK\Samples\C++ \Effects11). Thus, you could modify the effects framework for your own needs. In this book, we will only be using the effects framework as is, without modification. In order to use the library, you need to first build the Effects11project in both release and debug mode to generate the D3DX11Effects.lib and D3DX11EffectsD.libfiles; you will only need to do this once unless the effects framework is updated (e.g., a new version of the DirectX SDK may update these files, so you may want to rebuild the .lib files to get the latest version). The d3dx11Effect.h header file can be found in DirectX SDK\Samples\C++\Effects11\Inc.
For our sample projects, we place the d3dx11Effect.h, D3DX11EffectsD.lib, and D3DX11Effects.libfiles in the Commondirectory that all of our projects share code from (see the “Introduction” for a description of the sample project organization).
Is there any migration analysers available for MonoTouch ?
I have seen one for Mono, but not for MonoTouch.
Short answer: No, there is none at the moment.
Long answer
The situation is a bit different from Mono. In general you test a complete and compiled (against a specific version of the framework) .NET application with MoMA, to get a report of what pieces are missing (or incomplete) in Mono that could affect the execution of your application on other platforms (e.g. OSX and Linux).
Testing a complete applications for MonoTouch would reports tons of issues - since the UI toolkit is totally different. E.g. anything about System.Windows.Forms, WPF... would always missing.
However if your assemblies are already split into (something like) an MVC design it would be possible to test some (the non-UI parts) of them against definitions based on the MonoTouch base class library.
Finally if someone has an immediate need (or looking for a nice project) MoMA is available as open source and the evaluation versions of MonoTouch contains all the assemblies needed to build the definitions files. A bit of extra filtering could make this into a very nice tool.
Alternative
You can see a list of the assemblies that are part of MonoTouch and some platform restrictions (compared to .NET) you should be aware.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Any way to use some Scala for iOS coding?
Would it be possible to use the Scala.NET implementation, and then MonoTouch to run Scala code on an iOS device?
I have not been able to find a page with binaries of Scala.NET that I can test, so the following are just general guidelines as to what you can do with MonoTouch and .NET languages.
MonoTouch can run any ECMA CIL that you feed to it. When you consider using a new language with Monotouch, there are two components that come into play:
Tooling for the IDE
Runtime for the language
The tooling for the IDE is the part responsible for starting the builds, providing intellisense and if you use Interface Builder, it creates a set of helper methods and properties to access the various outlets in your UI. As of today, we have only done the full implementation for C#. What this means for an arbitrary language is that you wont get the full integrated experience until someone does the work to integrate other languages.
This is not as bad as it sound, it just means that you need to give up on using XIB files from your language and you probably wont get syntax highlighting and intellisense. But if you are porting code from another language, you probably dont need it. This also means that you would probably have to build your assembly independently and just reference that from your C# project.
So you compile with FoobarCompiler your code into a .dll and then reference in your main C# project.
The language runtime component only matters for languages that generate calls into a set of supporting routines at runtime and those routines are not part of the base class libraries (BCL). C# makes a few of those calls, but they are part of the BCL.
If your compiler generates calls to a supporting runtime that is not part of the BCL, you need to rebuild your compiler runtime using the Mono Mobile Profile. This is required since most runtimes target a desktop edition of the BCL. There are many other API profiles available, like Silverlight, Mono Mobile, Compact Framework and Micro Framework.
Once you have your runtime compiled with our core assemblies, then you are done
If you had read the MonoTouch FAQ, you would have noticed that it currently supports only C# and no other CLR languages.
Binaries for the Scala.NET library and the compiler can be obtained via SVN, in the bin folder of the preview:
svn co http://lampsvn.epfl.ch/svn-repos/scala/scala-experimental/trunk/bootstrap
Bootstrapping has been an important step, and ongoing work will add support for missing features (CLR generics, etc). All that will be done.
For now we're testing Scala.NET on Microsoft implementations only, but we would like our compiler to be useful for as many profiles and runtime implementations as possible.
A survivor's report on using Scala.NET on XNA at http://www.srtsolutions.com/tag/scala
Miguel Garcia
http://lamp.epfl.ch/~magarcia/ScalaNET/