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.
Related
A while ago, I developed a WPF control and integrated into a third-party solution.
Just my luck, turns out the supplier also now use nlog (v2), which they have registered in the GAC. They don't currently use an nlog.config file, although they could do at some point.
I have used nlog v4, which isn't registered in the GAC but resides in the project's output folder instead. I do use an nlog.config file.
Two issues I would appreciate your advice with:
How would I isolate our nlog config file, can I rename it?
Would it be considered good practice to register my nlog.dll (v4) in the GAC also?
Your second question:
Would it be considered good practice to register my nlog.dll (v4) in the GAC also?
I would not recommend to use the GAC if it's not required. It makes upgrading more complicated and it's less transparent. NLog 4 is fully semver compliant, so it's easy to upgrade when keeping your nlog.dll in your local bin.
I've been setting up Orchard 1.8 in an Azure Cloud Service. I've got it working, but I'm now confused as to how to use it.
Installing themes via the gallery fails silently. The devs say this is because Orchard on Azure doesn't support the theme gallery, and suggest adding new themes to the project and uploading a new package (https://orchard.codeplex.com/discussions/453688). Ignoring that this requires any designers that want to make minor CSS changes now need Visual Studio, access to the entire source code, and then wait through a 20 minute deploy, this just doesn't seem possible.
This post explains how the Azure emulator doesn't work with Orchard. So now I'm confused; what is the expected workflow for a brand new Orchard site hosted on Azure if I can't make changes to the site in production or staging but cannot run it locally either. I'm aware I could run it without the Azure emulator on regular IIS but that seems to be too far removed from the production environment to be a good test.
I was drawn to Orchard originally because it had great documentation and supports MVC Web API, but this seems so fundamental that now I'm not so sure. I feel like every time something goes wrong they'll always be doubt whether it's working as designed or if there is an Azure idiosyncrasy going on.
I'd love to hear from anyone who's had an Orchard site from scratch in Azure, I'm hoping I've just missed something simple with this.
Thanks,
Tom
You should never install modules or themes on a production server. Instead, install those on your dev machine, build the package and then deploy. If you don't want to deal with the heaviness of cloud services, don't use cloud services. Azure Web Sites are about a million times easier to use, and they work great. They allow for what you're asking for.
I'm using MS P&P Guidance Library for SharePoint 2010 in my custom solutions. Currently each solution builds wsp with including Microsoft.Practices.SharePoint.Common.dll and Microsoft.Practices.ServiceLocation.dll and when wsp is deploying it installs these assemblies to GAC, but when it is retracting it removes them. So I get a situations, when I deployed two wsp from two solutions, and then if I remove one of them I get second not workable, because it can't load Guidance Library assemblies.
Please tell me about best practices how to deploy P&P Guidance Library to farm separately from custom wsp's? And how to check in custom solution is there available needed assemblies in farm?
Currently I see two approach.
1. Install assemblies manually through cmd or PowerShell. It's not good because in this case I need to do it on each WFE.
2. Make custom wsp, which will deploy assemblies to GAC and activate some farm level feature, which will inform that assemblies have installed. And then custom solution must check this farm feature before activate it own features.
Thanks in advance for your advices!
I would advise you to have a separate WSP containing these two assemblies. This WSP must be installed first and treated as a prerequisite for any other WSP to work.
Your solution structure in VS needs to be changed for this. Create a separate project for P&P and let all other projects refer this project. But make sure that other projects do not copy the referred DLL's into the output folder. You can set this by setting Copy Local to false on the reference.
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.
In a normal ASP.NET Website there is a Web Deployment Project that we can use to pre-compile our entire website and then we can safely upload this project to our production server in order to protect our code.
What can we do for ASP.NET MVC 2?
Link to it as is available today (RTM version)
Visual Studio® 2010 Web Deployment Projects - RTW
Make sure you install the latest security patches for your operating system and hire a good network administrator. No kidding. No matter what you do if a hacker gains control over the server he will get the code under one form or another even if it is precompiled. This being said it is a good idea to precompile the application and deploy only the assemblies instead of the source code. You could also consider obfuscating it also but this is something usually done for client applications which you deploy to your users computers and less frequently done in server side applications because you control the server.