Is it possible to successfully deploy an assembly containing event handlers for a custom SharePoint list feature (thus, classes that depend on the Microsoft.SharePoint assembly) to a web application's bin instead of the GAC?
The option to do so certainly appears to be present in the XML markup in my feature's manifest.xml file. However, I've seen several references that deploying CAS policies for the assembly are a must with little instruction on how to successfully achieve this for an assembly that requires privileges like access to the SharePoint object model. I've also seen discussion suggesting that the GAC is nearly a requirement because of difficulties/issues with CAS.
I have been able to actually deploy the assembly to the folder. The security issues however, have been a big impediment. The only way I've been able to get my assembly to run (instead of simply erroring out with exceptions) is by elevating the web.config's trust level to <trust level="Full" originUrl=""> which won't fly in my environment. I'm hoping to verify that what I'm trying to do is possible before I continue to further wrestle with CAS.
If this is possible, if anyone has guidance or resources that would assist me in modifying my feature to deploy my event handlers in this fashion, I'd appreciate it.
Don't elevate the web.config's trust level - pretty large hammer for a tiny problem. You must package up a custom CAS policy in your WSP to grant your assembly higher privileges that the web.config bestows on it.
-Oisin
One way to approach this is to crank up the logging, record the various exceptions that are thrown and then write a CAS policy manually. This is a very probabalistic approach and rather painful.
It seems likely that all of the permission demands for any given method or class are known up front. If so, it should be possible to write a tool to statically analyse your code and dependant assemblies and compose the required CAS file. Unfortunately, I'm not aware of any tool that does this.
For what it's worth, GAC'ing your assembly seems much "lighter" than upping the trust level.
If I got your question right, you want to deploy a list event receiver to the web application's BIN directory.
This is not possible within SharePoint 2010, but I don't know if it was supported on MOSS 2007 (i guess it wasn't supported either).
This behavior is by design, because SharePoint internally uses the System.Reflection.Assembly.Load() Method to load the event receiver assembly. The Load() method does only work with fully qualified assembly names, thus requiring the assembly to reside in the global assembly cache.
Related
I'm writing a custom .net profiler to rewrite some methods in SharePoint 2013 on the fly.
The Class I'm interested is Microsoft.SharePoint.Utilities.DateOptions.
I've implemented ICorProfilerCallback::JITCompilationStarted and ICorProfilerCallback::JITCachedFunctionSearchStarted in my profiler and am currently just logging all functions being compiled. Also, I've set eventFlags as follows
DWORD eventMask =
COR_PRF_DISABLE_ALL_NGEN_IMAGES |
COR_PRF_DISABLE_INLINING |
COR_PRF_MONITOR_JIT_COMPILATION |
COR_PRF_MONITOR_CACHE_SEARCHES;
The problem is, No matter what I do, no method of DateOptions class will be compiled. I am sure that it should be called, and I've already tested my changes by disassembling, updating code, and reassembling it's DLL. I can see other classes in the same namespace loading and compiling (and can successfully rewrite them) but not this one. The decision to use a profiler for the job is a business decision and can not be reverted.
One point of interest is that this class is used on the code generating the page and its web parts, and I can see no other related classes in this code-path too.
I've enabled my profiler system-wide using system environment variables, and have tried rebooting so it will profile everything from startup to no avail.
Am I missing something here?
Edit: I guess it should be some setting inside IIS or something. I can see all normal classes and namespaces, but nothing that runs while rendering the page in IIS.
I finally solved my problem. It was kind of a dumb mistake I guess, but still I'm putting it here so no one else gets stuck like me!
I was using a specific folder on my C drive for development, and ASP.Net user account did not have read privileges to that folder, and could not load the profiler.
Parts of the process was run using a privileged account so I was able to log and rewrite it's functions, but the web rendering parts were under a limited account.
Copying the dll to System32 folder fixed all my problems.
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH
I am seeking advice: Ideally, I would like to give an Administrator (of the web server) one file (.exe, .msi, .bat, whatever you suggest), so that when they execute the package, it will setup my application (contains .aspx, .xap silverlight, web service .svc, etc.) on IIS. This will include and certainly not be limited to such things in the IIS Manager, like creating a virtual directory, path, default document, security, and all of the IIS settings one finds via inetmgr and properties. I would also maybe like to run a .bat file (not sure if this correct), but to check for certain settings and pinging other servers for status.
Many years ago, I used to automate everything and used concepts like .bat files - got the job done and it was amazing what I could do. Fast forward a couple of years now and am approaching the automation process again. I wanted to know if there is anything new out there.
Any and all advice will be greatly appreciated!
It's quite a bit of a learning curve but yes, WiX / InstallShield / MSI can do this. I've done installers for n-Tier / SOA systems including single tenant SaaS where you could run the application layer installer dozens of times creating new instances running on different host headers or ports pointed to different data layers and different configuration settings. You could then do the same for the WebUI pointing to which ever application layer you want.
Basically whether it's instaling .NET, setting up vDir / AppPools / WebSites / Extensions, reading and writing XML config files, executing SQL scripts, creating services and so on it can all be done... if you take the time to learn it all. Deployment Engineering is a bigger domain then it first appears to be.
As for .BAT, that's bad form. First you work to leverage native capabilities before writing custom actions. Then when you do have to write one, you design it to be declarative and transactional ( install, uninstall, rollback, commit ). WiX has a really nice framework called DTF that allows you to encapsulate C# classes as if they were C++ from MSI's perspective and provides a nice interop library needed to talk to MSI during the install.
Visual Studio has a Web Setup Package project you can use for this.
I feel like I need a better defined framework for updating my SharePoint (MOSS 2007) application with custom code changes. I am creating wsp solution files with features and new types and such, but once those get tested and deployed, I feel like it's a bit of a leap of faith, and that makes me nervous and occasionally reluctant to deploy changes. After deployment, it's difficult to correlate the current state of the SharePoint application with the specific code that is deployed on that SharePoint server. What features are actually installed and on which sites? Which features are activated or deactivated? Which version of this custom field or content type is really there? Things like this. If an error crops up, I have to rely on my assumptions about what code is there and actually running, or I have to spend time digging through deployed assemblies and the 12 hive -- not impossible, but pretty unpleasant.
What steps should I take to improve my ability to unambiguously determine the state of the application and find the code that truly represents that state? Are there third-party tools that can help with this?
I feel your pain... Application Developyment Lifecycle with SharePoint 2007 leaves me with a bitter taste in my mouth.
To answer your question. We built our own deployment utility that does a few things for us.
Checks state of key Timer Jobs (too many times we would do a deployment to find one WFE that did not get deployment)
Checks state of key Services on all our web front ends (again we want to know health of farm before we start kicking off timer jobs).
Shows file version and date of selected assemblies from GAC (does this across all Web Front Ends). We have seen problems before where assemblies did not get installed correctly across the farms.
Updates web.config settings based on an custom XML scheme we provide. We ran into some problems with web.config updates so we have thought about creating a utility to validate the web.config (specifically make sure there are no duplicate entries for specific keys).
Push content type updates (first time content types are deployed via feature it works great, but as soon as you need to update that content type it gets tough).
Checks status of WSP package after deployment or upgrade.
This utility uses the SharePoint API to do most of this work. Some of it is done by checking WMI Events.
Unfortunately the SharePoint development experience is lacking in this regard. As long as you are "namespacing" all features deployed using solution packages, you can use solution management from central admin to keep track of versions, and what gets deployed to which site collection.
Features are scoped from all levels from the farm to an individual web; so maintenence from that level is a little tough. I just try to organize all deployed code from the (top down) solution level.
It gets even more complicated when deploying custom timer jobs, event handlers, etc; I really hope that version next will address a lot of these common developer concerns.
Isn't the only way that you have a planned/controlled deployment process and a version management system like TFS
In the current project I am involved in we have:
Continuous builds
Daily Builds on a development server
When we release something to test we merge the code to the Main bransch in the version management system (TFS)
When tested and ready for production then we merge the main bransch to the release bransch
Using this structured way we always knows what is deployed in what environment and can also track all changes based on environment or changes in requirements(are also tracked in TFS)
I’ve inherited a SharePoint solution where all the projects have strong names and are deployed to the GAC.
I find that its difficult working with projects that are signed, it slows down development, testing and makes debugging difficult.
So, is it possible that SharePoint projects, WebParts, Codebehinds etc be deployed to the local bin instead of the GAC? Is it considered bad practice to deploy to the local bin?
It is always recommanded to use the Bin directory over to GAC, for all the WebParts & Code Behinds. As that will restrict the Trust given to the code, GAC provides full trust to the code.
After deploying to the bin you can gain the required permission using CAS.
I recommend you to read the chapter Application Security of Inside Windows SharePoint Services 3.0 Book
Note: You will have to deploy your code Feature Handler, Timer Job etc to the GAC
By default, SharePoint Web applications are only allowed to run with a very restrictive trust level of WSS_Minimal. If we want to have our Web Part deployed to the bin folder, then in order for it to run we must do one of two things: either set the trust level to WSS_Medium or WSS_Full in the web.config, or create a custom CAS policy that will allow this assembly's managed code to run. In a production environment, you will need to make an informed decision on this yourself.
I would use the GAC for local development and testing and use the bin in production.
To debug locally, check the following in your config file:
customErrors=off
Enable Stack Traces by adding CallStack=”true” to the SafeMode tag
Set the compilation debug attribute to "true"