Universal apps allow sharing of common assets in the Shared Project, including XAML pages. However the Hub App (Universal Apps) project template creates two distinct MainPage.xaml files in each platform-specific project.
Is there any reason for this? Am I going to regret putting all of my XAML files in the Shared Project?
If one XAML file can be used for both platforms then put it into the shared project. If the views differ too much between the platforms or the UI performance is bad when sharing XAML code then you should create separate XAML files and put them in both projects.
Putting the XAML file into the shared project is the same as having the same file in both projects. Adding files to the shared project is the same as linking files into a project - just more convenient. (Read this article about file linking and PCL)
I recommend to start with everything UI (e.g. XAML, converters, ...) in the shared project and view models and logic in an external PCL library (with W8 and WP8.1 targets).
If a view/XAML file is different in W8 or WP then you can copy the XAML for this particular view into both platform specific projects.
More detailed information:
http://blog.galasoft.ch/posts/2014/04/about-windows-phone-8-1-and-universal-apps/
Related
I'm working on a xamarin forms (PCL) project (A basic customer care chat app which is meant to run on Android and iOS only) that has just two xaml pages, custom renderers and few dependencies. This project is meant to be implemented into another existing project (which I don't have access to its source code) such that an action would be binded to a button on the existing app to show a page on my own project.
There is need for me to share my chat project with my client's developer but without exposing my source codes, perhaps compiling to dll or nuget package that would be added to the existing project to access my project's functions and pages. I have searched through the xamarin forum and here on stackoverflow but can't seem to lay my hands on a solution.
Is this possible at all? If yes, what am I missing? If no, is there any better option to use?
Please do note that the chat app completely done, so I'm hoping perhaps there's a way I could directly convert the project to a Nuget package.
Thanks in anticipation!
If the host application is a Xamarin Forms one:
-Move your cross platform shared code into a PCL or .Net Standard (ContentPages, ContentViews, Classes).
-Move your Renderers and platform specific code to Android and iOs Class Libraries.
Your client will have to reference your first assembly (dll) in their XF assembly in order to instantiate/manipulate your views/classes and platform specifics one on their Back-end side (taking into account your renderers, effects, etc ...)
A lot of Xamarin Controls Libraries Open Source hosted on Github are working like that. For example this one: https://github.com/jamesmontemagno/Xamarin.Forms-PullToRefreshLayout
If the host application is a native application, take a look into Xamarin forms embedding
Finally, I seem to solve the problem by enabling visual studio to build Nuget packages for the chat app project (summing up to 3 nuget packages) on project build.
Thanks #Rudy Spano and #Micah Switzer for your contributions
In ASP.Net Core the convention for projects seems to be to put the ASP.Net Core projects inside a src\ folder, and the test projects inside a test\ folder.
What other conventions are there, ie. where should a web (front-end only) project be located?
The honest answer to this is "it depends." The src and test folders at the root are a common structure seen in code repositories today.
Here are some common root folders and what they may contain:
test - Unit tests, UI tests, Integration tests, etc.
src - Source code projects
tools - Strong-name files and/or 3rd party tools that may be used to help tests or builds
build - Scripts to perform various builds on the project
docs - Documentation files for the project
How would you organize a web (front-end only) project inside an ASP.NET Core directory structure?
The only advice I can give without knowing your project, and the people interacting with it, is to keep it simple. I haven't found a need to add more root folders beyond what's seen above.
Keep in mind that there are certain folders that a default project template is going to use:
By default, Grunt is set up to look in the css, js, and lib folders under wwwroot for its bundling process.
Bower (also with the default template) will install packages into the lib folder under wwwroot.
MVC looks through the Views folder for view templates.
For a customer we have an ASP.NET MVC plugin architecture consisting of:
- 1 core web application (this is the root web application in IIS)
- X plugins for which the content (views, css, scripts) are deployed in a sub folder (Areas)
The assemblies of the plugins are deployed in the root bin folder
The plugins are created by separate teams and these teams should be able to deploy a package to a server.
The package (ran by administrators) should make sure the plugin is deployed correctly (in a sub folder of the core) and the dll files should be deployed in the root bin.
I guess a deployment package should be created.
How can this be done or what are good practices around this?
How can I customize the way a package will be interpreted (MSBuild)?
Bit of a late answer, however I have been using a method of creating 'pluggable' areas similar to that discussed here and here.
What these articles talk about is a method to turn areas into separate web projects which can then be bin deployed with the original web app when required.
I have extended their methods with a custom ViewEngine which inherits from the Razor view engine, to look for Views in a specified folder location (I named this folder 'Modules'). This is dynamic based upon whether the modules are included or not (I search for modules in the Modules folder on app_start).
Hope this helps!
In VB.NET, my application is quite simple, and it accesses many images and creates a list with them.
The images are in my application's Resources folder.
The images are accessed in my code where I typed the path, in my PC, how to reach said folder.
Works like a charm, my project displays the images etc.
Now I go to Debug->Build.
Now I go to the bin folder, release folder, and find my application. I upload it.
I share the download to a friend.
My question is, will the images my application should show will appear? Considering the path I created in the code was manually written?
Are the images compiled into your project as "Embedded Resources" or placed in a .resx file? Is the code that you've written accessing them from your project's Resources folder? If so, then everything will work just fine when you copy the application to another computer and run it.
If you're hard-coding a path to your file system, then no; your application won't work on another computer because those files won't be distributed along with the bare executable. There's really no reason to ever do this.
It's difficult to tell from the information provided in your question what exactly you're doing. For more information about embedding resources into your application itself, so all you have to do is distribute the executable, see this simple how-to guide: Using Resources in Visual Studio .NET
Questions:
Are XAP files self-contained?
Do they link in all DLLs I have referenced in the project?
If I need to distribute my app, is all I have to do is hand someone the XAP file?
By default, yes. For alternatives, see answer 3.
By default, all except the core DLLs installed by the runtime; it will contain anything from the SDK, Toolkit, 3rd party controls, or your own libraries.
By default, yes. However, there is an option as of Silverlight 3 to package certain assemblies (for example anything from the SDK) into separate ZIP files, which are downloaded separately. In Visual Studio, look in the project properties for a checkbox called "Reduce XAP size by using application library caching." This option toggles whether to create/use the ZIP files or not. Enabling the ZIP option allows multiple Silverlight apps to share the dependency on the ZIP files, so that instead of packaging everything into the XAP every time, you just download the ZIP for one app, and it's saved in the browser cache for other apps.
As for the general contents of the XAP file, there are 2 important bits:
Foo.dll - your project's main assembly (renamed as appropriate)
AppManifest.xaml - describes the requirements for you app, e.g minimum runtime version required, the entry point into Foo.dll, and other settings, including Out-of-browser settings, or whether to use the Library caching feature mentioned above.
Anything else is just content used by your app.
Silverlight XAP files can be tricky if you're using anything other the the core silverlight assemblies (eg. SilverlightToolkit).
XAP files are just zip files - open one up and take a look. They are self contained to the extent that any custom/extra dlls are included - the standard Silverlight assemblies will be installed when a user installs Silverlight.
References to dlls are required in the .proj files for every assembly that will be used. Ie. unlike other project types, if one project references another project, both projects need to reference all dlls used by either project.
You should be able to just hand someone the XAP file if you want - but Silverlight was designed to be used in browsers, so you will need to include the generated test page at least. The best, and most useful, is to provide a publicly accessible web page that hosts your silverlight app.
HTH.
Even though this question is already answered, i'm going to throw this one in too because it hasn't been mentioned yet.
You mention that you are using SL4 - if you are running out of browser (OOB) then you can just ship the XAP file, and use sllauncher.exe (2) to "install" it to the client machine. As part of that install you can also specify where updates are to be sourced from, which is important for when you find bugs or the requirements change.