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.
Related
I have an existing project using RIAServices with Entity Framework. The project builds correctly and generates the AmsiWeb.g.cs file with all the context classes for my services.
I am converting my designer based entities and ObjectContext with Code First entities and DbContext. I installed the RIAServices.EntityFramework NuGet package to the web application that contains my services. However, now when I build the AmsiWeb.g.cs file only contains the WebContext class. It doesn't contain any generated services.
I have only at this point converted a single EDMX model to Code First and DbContext and made the requisite changes to the services that use that model to inherit from DbDomainService.
I am using EF 5.0... not sure if that matters cause I'm not sure how adding a DLL to the AmsiWeb application project would break code generation.
What would cause this to no longer work and how can I fix it?
Maybe it's a problem within the msbuild task that generates the proxy code (I mean the *.g.cs file). Probably it's looking for the wrong version of a entity framework. Have a look at this blog post http://mcasamento.blogspot.it/2012/10/entity-framework-5-code-first-and-wcf.html in the final part I wrote an assembly redirect statement that did the trick
It turns out that their needs to be a redirect for Entity Framework 5.0 (4.4.0.0 since I was using .Net 4.0) in the web.config. But, since my RIA Services were in a web application project that was not my root project the code wasn't generating.
Once I added the redirect to the web.config of the web application with the RIA services in it, the context code was correctly generated.
I am learning how ServiceStack works with the help of self-hosting projects.
Self-hosting projects are much easier to debug and understand, since no magic happens inside IIS.
I followed these steps, read http://www.servicestack.net/mythz_blog/?p=785 and applied them backwards.
It worked fine for Docs, but not for the SocialBootstrapApi. The code in Application_Start() from Global.asax is the problem I think
Steps for ServiceStack Docs
Download the ServiceStack Docs sample project
Create a new console project (.Net 3.5 since Docs is still 3.5)
Copy all files from old web project except web.config. (I first used drag and drop, but that only moved the file, it didn't update the .csproj file, so I had to use an editor to copy some ItemGroup sections.)
Move AppHost into a separate class file, changed to inherit from AppHostHttpListenerBase
Copie the Programs.cs file from the RazorRockstars project
Change the baseUrl: var baseUrl = "http://localhost:2001/"; // ConfigUtils.GetAppSetting("WebHostUrl");
Copy the app.config file from RazorRockstars project (but this wasn't needed)
Change output path for console project to .\ because otherwise PageManager.Init got the wrong path and most files were not found
When you done this, download the complete ServiceStack source code and recompile in Debug mode, replace all ServiceStack references in the Docs project by the newly compiled things. Now, you can easily step through all ServiceStack-code, set breakpoints etc, and understand what is happening and when. Console projects also have some other advantages, they start faster, Edit-and-Continue works more often.
For SocialBootstrapApi I did the same except/and
Renamed web.config to app.config
Commented away // [assembly: WebActivator.PreApplicationStartMethod(typeof(SocialBootstrapApi.AppHost), "Start")]
Now, the normal ServiceStack part of the project works, although the url is without the initial /api/
Tried moving Application_Start() from Global.asax to AppHost.Configure ==>> Refuses to start
ASP.NET MVC can't be hosted in a self-hosted HttpListener (since it's coupled to ASP.NET), but ServiceStack does support hosting it's Razor and Markdown view engines inside a self-hosted HttpListener app.
The Razor Rockstars website is a show case website of ServiceStack's Razor and Markdown view engine support. razor-console.servicestack.net is the same website hosted in a HttpListener self-host. The source code of RazorRockstars is on GitHub with the RazorRockstars.SelfHost example contains the source code for razor-console. The one thing you have to remember with self-hosted websites is that the Razor view pages Build Action in VS.NET needs to be set to Copy if Newer so the views are copied in the /bin directory so they can be found by ServiceStack at runtime.
I'm using log4net logging in my software that consists of several applications.
I want to have one common library for this.
I created a library and put it in the conficuration file. In AssemblyInfo.cs placed attribute:
log4net.Config.XmlConfigurator(ConfigFile = #"c:\logging.xml", Watch = true)
It work for windows service, but in dosn't work for asp.net application.
It work in asp.net if delete attribute from common library and put in into global.asax. However, this leads to that section of the log4net configuration must be made in the windows service.
There is also a business process which causes our library through the
remouting. I want the logging was carried out there too.
Is there way around this?
In my opinion the library should not define where the configuration file is found. Maybe a better idea would be to have a helper method that allows you to configure log4net quickly; that method would take an optional parameter for the config file path and would try to load the configuration file from the specified path first and if that does not work fallback to some maybe the current folder, the application folder or even the web / app.config.
If you insist that it must be an absolute path then you need to give the IIS Application Pool user read access to this file. This way the configuration by attribute should work for services and ASP.Net applications. I do not understand what you mean by "remounting".
Can T4 templates be used in a web site project?
Or more specifically, can Subsonic be used in a web site project?
I can run the .tt files in a web application project but it does not nothing on a web site project. I guess they need a solution/project environment in order to run?
The easiest way to do this is to add a class library project to your solution and then have SubSonic do it's generation inside that. You can then reference the class library from your website project.
Edit To clarify you'll need an app.config in the library project with your connectionstring for gernation and you'll need a connectionstring in your web.config for runtime database connection
I believe they need a project to run. I blame it on microsoft.... so perhaps adding a lib project would work. Don't know if the runtime connection string should go in the web.config or the dll's config, though.
We have a class library where we keep a lot of the stuff that we often use when doing sharepoint development. How would you go around deploying this? Right now our best bet is to have it in a separate solution, and deploy that so that the assembly is deployed to GAC. That way we ensure that the assembly is deployed to all application tiers and is available.
Is there a better approach than this?
GAC, of course, is the easiest way to deploy an assembly; however, what if you don't want to share this assembly across an entire server. Or what if the license doesn't permit that.
So, there are two ways to deploy an assembly:
GAC (you already know about it)
BIN folder. To deploy your assembly to the bin folder of your site (e.g. C:\Inetpub\wwwroot\wss\VirtualDirectories\80) you'll need to create a custom Security Policy file and change a security level in the web.config. This is not easy at all and can be quite frustrating but may be well worth it.
More information: http://msdn.microsoft.com/en-us/library/cc768621.aspx
The GAC is usually your best choice. Like ensuring you deploy to all applications, it's also easier in terms of security.
If I remember correctly, putting it in the GAC is the recommended course of action.
Also, remember that you have to add to the SafeControls list in the web.config.
http://grounding.co.za/blogs/brett/archive/2008/05/23/sharepoint-register-an-assembly-as-a-safe-control-in-the-web-config-file.aspx
I've decided to deploy it to GAC since the assembly doesn't pose a security risk since it will not be used from Web Parts.
I've researched a bit and deploying to gac is the recommended way to do it. You could argue that everything but Web Parts should be deployed to GAC. Since Web Parts pose a potentially security risk it can be a good idea to make your own CAS and deploy it to sharepoint bin.
Cheers.
Note that if you do decide to deploy to the BIN folder, you can deploy custom security policy settings such as new Permission Sets through your solution manifest file.