I am using the code from the
Microsoft ASP.NET Identity Samples 2.1.0-alpha1
There's one area of the code that I do not understand and that is the web.config entry below:
<appSettings>
<add key="owin:AppStartup" value="IdentitySample.Startup,WebApplication3" />
My code does work without this but I am wondering if I should have something like this.
Can anyone explain to me what this does?
Basically this tells OWIN what method to execute on the application start. And IdentitySample.Startup method contains code that bootstraps your application.
You can specify this class via an attribute [assembly: OwinStartup(typeof(StartupDemo.TestStartup))] if you wish.
But this one is web.config so it can be changed for different deployment strategies without recompiling the project.
See more details in documentation.
Related
I have built an API using Loopback. Now that it's time to host it on my Windows machine, Googling turned up two distinct options: 1) using NSSM to create a Service, or 2) using IISNode, a IIS module, to host the API using an IIS process. Since the benefits of using IIS seemed too strong to ignore, I chose that option.
The loopback documentation states that iisnode can be used to host a loopback api, but then fails to provide any guidance on the topic.
Iisnode documentation also has a few very basic examples, some based around Express (which loopback is built upon), but doesn't make it clear how to adapt a loopback application for use with iisnode. In all of their simplistic examples, the main node file is located at the root level of the node project. Loopback, however, keeps its at "~/server/server.js". This makes it unclear about where to place and configure the web.config file necessary for iisnode to work.
Is anyone aware of a decent tutorial or walk-though for hosting a Loopback project in IIS using iisnode? All I found are vague articles stating to the effect of "well...it should work." Has anyone successfully hosted a loopback project using iisnode?
Make sure you follow this small check. Loopback hosting on web servers has a known issue(Not exactly an issue, but a protection feature, which can trip up first time deployer):
https://github.com/masonkmeyer/loopback-azure
The app.start() is called only when loopback's server.js is invoked directly. But webservers like IIS usually invoke the main script by requiring it. The solution suggested above is a little inelegant, in the sense that it does not guarantee that app.start will be called only after boot completes setting up rest endpoints.
Otherwise the web.config is pretty straight forward. The following helped me with the configuration a bit:
https://tomasz.janczuk.org/2011/08/using-url-rewriting-with-nodejs.html
I'm not sure that you need a Loopback specific tutorial to help you out here. You just need to modify your Web.config.
Inside your Web.config there needs to be an iisnode handler. This instructs IISNode which file is the main file in your project. To direct traffic to your server file path simply change the path attribute on the handler.
<handlers>
<add name="iisnode" path="/server/server.js" verb="*" modules="iisnode"/>
</handlers>
I've created a couple different walkthroughs for setting up an IISNode app with Express but they are applicable to really to anything being setup with IISNode.
This answer
While trying to integrate the below example in my solution I am getting the below issue.
https://github.com/AzureADSamples/NativeClient-WindowsStore
Attempt to access method System.Management.Instrumentation.InstrumentedAttribute..ctor(System.String) in violation of security transparency rules failed.
tried to add the key <trust level="Full" /> but it doesn't work.
Any help/pointers will be highly appreciated
I had the same problem, but I resolved it.
I had this code in one of my assemblies (it is a custom implementation for Enterprise Library):
[assembly: Instrumented(#"root\EnterpriseLibrary")]
For some reason, the search for Owin Startup attribute does not like this
I was trying to explore some ASP.NET-5 applications where I found the startup.cs file. Where we set out routing and all (of course not only for routing). I also see some demo where has shown the use of dependency injection here. So, I'm looking for answers to the below questions:
Why this startup.cs is? What it does?
What are the uses of this file?
What is the advantages of this?
And is there any good documentation to know the use of startup.cs in details. And why the application does not work if we change the class name 'Startup' to something else?
I do have very elementary idea about OWIN and pipeline. Please help me to find these answers.
Just repeating here what it's said in Getting started with vNext
By default, the vNext hosting environment expects to find a startup class named Startup.
This class must contain a Configure method that takes an IBuilder parameter, and you configure the HTTP pipeline inside this Configure method. The empty project creates the class with nothing in the Configure method.
I would recommend you to take a look on vNext Moving Parts by Louis Dejardin since it explains a bit more about OWIN pipeline and vNext.
Sorry for not being of much help!
I'm running a Node.js server as API for my mobile app on a Windows Azure Website. And I'm having some trouble with it due to the needed web.config - but I couldn't find any really helpful documentation about it. Everything I can find is googling for specific problems on it and with a bit luck I can use the config snippets.
is there any general documentation about the contents the web.config can contain and their meaning?
in the start I had the problem that errors were modified by IIS to a general error. But since it's a REST API I want the HTTP status codes to be returned. I got around that with the <httpErrors existingResponse="PassThrough" /> element, but it doesn't seem to work for every error.
The only documentation I found so far are example configuration files of the iisnode module.
If you see the following error:
web.config not found in project, to create a project to deploy to
Windows Azure you must create a Windows Azure Node.js project.
....you may have created the wrong type of Visual Studio Project. You want a "Windows Azure Node.js Application" not a "Node.js Web Application". The former creates a few extra files that are needed for Azure (Web.cloud.config & Web.config).
You may be able to create a dummy VS project of the correct type and then copy these files into your existing project. Alternatively create a new project of the correct type and copy your source files into the new project.
Create Azure Basic Node.js Express Application
Working on a SharePoint project I'm trying to use Unity as a dependency injection container.
My first idea to get this container running is using the global.asax as described in the best practices by P&P:
http://webclientguidance.codeplex.com/releases/view/17134#DownloadId=43305
In these best practices they tell you to manually edit the global.asax file to make it inherit SPUnityHttpApplication.
<%# Application Language="C#" Inherits="Unity.SharePoint.SPUnityHttpApplication" %>
Manually editing this file is not an option in enterprise environments since we have multiple environments (DTAP) and all of them have multiple frontend servers that would need manual steps.
I can't find any way to deploy a global.asax file by using a feature or wsp or anything because the global.asax is located in the web application root and sharepoint deploys other files to the /14 hive folder so you can't acces the web application root directory.
Alternatives i've looked into is the SharePointServiceLocator. this build in functionality does almost what i want. but it can only resolve classes that have a default constructor. this way i can't chain resolve all my implementations by using constructor injection. I found a post how to change the service locator to make use of unity but this doesn't seem to work properly if you read the comments.
My problem can be fixed by fixing 1 of these 2 main problems:
Don't arrange unity in the global.asax, but then where and how?
Deploy the global.asax in sharepoint? possible?
The global.asax doesn't seem to be the best solution to do this because of the deployment issues described in the question.
A viable solution is implementing this in a httpmodule
The init method can be used to wire everything up since this is called when the sharepoint application starts.
the httpmodule can be added in the web.config by a feature receiver
This way there is no need to do tricks with the global.asax that is located in a directory you can't deploy to with a feature and you have all the functionality and correct time to instantiate the DI container.
It may not be ideal, but you could look at using a feature receiver and write code to edit the existing files directly.