How to package/deploy udash application? - udash

I developed a http://udash.io/ application. How do you package the web application for deployment?
I tried the sbt native-packager plugin, but it seems resources are not picked up, e.g. the static web assets.

You have to configure custom Mapping.
For example: mappings in Universal ++= directory("target/UdashStatic")
More about mappings: http://www.scala-sbt.org/sbt-native-packager/formats/universal.html#mappingshelper

Related

Is there a standard or convention in doing configuration in .net core 2

Is there a configuration provider already pre-configured in .net core that I can just use without having to add in boilerplate code? In the same way that app.config files just work in full .net.
I'm writing a console app in .net core 2 and it needs some settings, a connection string and a few app settings that I would have previously just tossed into the app.config file.
I've started googling about configuration in .net core and found a whole heap of documentation about how flexible it is - you just add a file, make sure it gets copied to the correct location and then spin up a configuration builder add it the correct provider build it etc. etc.
As nice and flexible as it is I don't want to clutter up my tiny console apps with this config boilerplate - it feels like we have to roll our own config for each app.
Ideally, in a .NET Core application, one would choose JSON setting files over XML configuration files, but it is still possible to use legacy XML configuration files if needed.
There is an API to access application setting files; just check out the following NuGet packages: Microsoft.Extensions.Configuration and Microsoft.Extensions.Configuration.Xml, and this article might be a good reading: http://benfoster.io/blog/net-core-configuration-legacy-projects since it also covers the integration of app.config or web.config files, as well as how to create a custom configuration provider.

Universal (EXE/Web) .NET config reader

I need to write a .NET 4.5 component which potentially can be used by .EXE or Web applications. This component has a number of configuration parameters to be provided - in main app.config or web.config accordingly.
Is there an universal API to read config or at least a way to determine the mode?
The System.Configuration.Abstractions library from David Whitney works across both desktop and web applications. You can install it with nuget:
install-package System.Configuration.Abstractions
There's documentation on the Github site, but in a nutshell where you'd use ConfigurationManager or WebConfigurationManager, you can instead use System.Configuration.Abstractions.ConfigurationManager.Instance (or use IConfigurationManager and inject an instance)
For App.config (desktop applications, foo.exe.config) use:
https://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager(v=vs.110).aspx
For Web.config, you need to use:
https://msdn.microsoft.com/en-us/library/system.web.configuration.webconfigurationmanager(v=vs.110).aspx
Abstract both of these and you're covered.
To determine whether or not you're in an ASP.NET environment, I have used System.Web.Hosting.HostingEnvironment.IsHosted in the past.

Deploy Web-Api, Asp.net project and a Windows service in one msi project

Is it possible to deploy ;
1- a web-api project
2- a website written in Asp.net
3- a WCF service as windows service
in one msi file using/in Windows Web Installer Project (preferably) or in Wix ?
Yes, it is possible using WiX. I maintain an open source project called IsWiX that even makes it somewhat easy. See:
Create and Package a Windows Service using IsWiX
IsWiX Web Site Demo
The concept behind IsWiX is project templates (scaffolding) and graphical designers that give you a project structure and most heavy lifting for your WiX MSI project. The template already contains examples of IIS configuration that merely need to be uncommented out. If you need a Web API and a Web Site you'll have to clone that part of the code and make a few adjustments. For example a static website typically won't be a web application where a web-api will be. Then you'll use the services designer to define the windows service. The fact that the service hosts a WCF endpoint really doesn't matter.
For that matter, one of the really cool things about WCF is it's possible to eliminate your dependencies on IIS. I've seen solutions using this with no dependency on IIS and this really makes creating installers a lot simpler.

Making a Pipeline available to any Application

I have a pipeline that I need to reuse. I need to be able to chose this pipeline from any app as I can with the XML or the Passthrough pipelines.
Is there a way to publish a pipeline to the Microsoft.BizTalk.DefaultPipelines namespace?
Look like you have the asnwer but I want to clarify a couple of things.
As you're discovered, BizTalk.System is a readonly system Application and cannot be modified.
The .Net namespace Microsoft.BizTalk.DefaultPipelines actually has nothing to do with it.
For all your shared components, you would create a new Application container in BizTalk Administrator called "My Shared Components" or such.
Then Add Reference to this Application to make Pipelines and Maps deployer there available in the local Application.
Final point, Add Reference only affects the visibility of Pipelines and Maps in BT Admin Port Configurations. Any other GAC'd components are available by the standard .Net rules.
Off the top of my head, can't you deploy (add resource) to BizTalk.System?

What is the best way to implement a plugin architecture for asp.net webforms application?

We have a 3-tier web application written in ASP.Net Webforms where we will not be able to port it - recession really sucks! - to MVC. Our goal is to implement a plugin architecture. One way would be to use the App_Code folder. Are there any better alternatives?
My plugin architecture is developed in a completely separate solution. I include a reference to the libraries in my web project. I use a plugin manager that runs in Application_Start and loads the plugin configuration from the web.config file. The configuration specifies the full name of the actual plugin being used and uses Activator.CreateInstance to instantiate the plugin. All plugins implement an IPlugin interface as well as an interface for each specific type of plugin.
Make a plugin-loader assembly maybe? :)
Avoid business-level code in ASP.NET applications. Try to keep it as "presentation only"-alike as you can..

Resources