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!
Related
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.
I have a Web Site and Class Library built with ASP.NET 5. The Class Library depends on an set of external files (XML, EXEs, etc.). Those dependencies are added as part of the project and visible in the Solution Explorer of Visual Studio.
My Web Site has a dependency on the Class Library. When I build the Web Site, I would expect the dependencies of the Class Library to be copied to the Web Site, but they aren't.
The Build Action (Copy always, Copy if changed) appears to be gone with ASP.NET 5. How do I make sure that dependencies other then the DLL of the Class Library itself gets copied to the Web Site project?
First thing first, they won't be in src/yourProject/bin/Debug. Those have been moved to the artifacts folder.
Also, your project by default will not output DLLs. This is mainly due to performance reason but if you need your DLL to publish your application, check your project properties. In the Build section you should have an option called Produce outputs on build. Tick that and bingo.
You have your dlls. Most of the time (aka: while coding), you won't need them since they will always be recompiled in memory.
You need to manually add a pre/post build step in project.json
Short introduction
My goal is to get IIS 8 to run an asp.net 4.5 website. Currently I have a CI server that pulls from version control and builds the web application with MSBuild.exe with this line of code
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe C:\project\WebApplication\WebApplication.csproj /T:Package
The problem
The problem I am facing is that I dont understand why things like Controllers, Viewmodels, Models etc. that are pure C# code are being ignored or skipped when the project is being built with MSBuild.exe and packaged.
The package that MSBuild.exe returns only contains
Areas
bin
Content
fonts
Scripts
Views
and is missing many folders including
Controllers
Models
etc.
Questions
Is this normal?
Why does this happen?
What am I doing wrong?
Seems to be
No idea, but the functionality of the cs files is now probably part of dll's in the bin folder.
I was not doing anything wrong. I just thought this was a problem. I managed to get the asp.net web application to work on the web server like it does on the developer machine.
I'm using YUI Compressor as a MsBuild Task on my Azure project. It works well on locally but when I try to publish it I cannot insert minified packages to my azure application package. Although I have tried a lot of things about package modifying on my .csproj file I couldn't work it out. How can I do this?
Edit:
My project is not a MVC or Webforms application. Just HTML and Javascript inside of an ASP.NET project. My problem is not minification. It is just placing minified external files in Azure Package when publishing it but if there is any other method that solves this azure problem, I can change YUI Compressor with ajaxmin or google closure... doesn't matter.
I don't think modifying the service package is supported (you are also modifying the manifest). That's why I would look at it from an other perspective. I'm assuming you have such a setup:
Solution
Empty ASP.NET Project
Index.html
App.js
Now, after you compile (and the MSBuild task runs) you'll have something like this:
Solution
Empty ASP.NET Project
Index.html
App.js
App.min.js (not included in the project, but available on the file system)
Now, buy simply including the App.min.js file in the project, it will be included in the service package when packaging or publishing your application. And besides that, the MSBuild tasks runs each time you compile, meaning the file will be updated before each time the application is packaged.
As you haven't specified about about whether it is WebForms or MVC, I would like to point out the out of the box support for the bundling and minification in ASP.net MVC4. Scott Gu has explained it the MVC4 preview demo.
You can also tweek it to work a way for that in ASP.net MVC3 too. Once this is achieved, you can achieve that in Azure as well.
Additional Articles :
ASP.NET MVC4 bundling in ASP.NET MVC3
New in ASP.NET MVC4: Bundling and Minification
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.