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.
Related
I have set two websites in my IIS 8.5. I have one for production version and one for development (need this for the team work purposes). The structure is simple. Website is simple static page using BackboneJS and API calls to get all the data. All virtual paths and applications were set at the beginning manually by my self. For some reason some API calls didn't worked in dev site. I found out the physical path to the API project has changed. Do you have any idea, where can be the problem? Actually some of my collegues face this issue too.
Only think that cames to my mind is that when bdebugging the API, I use "Attach to process" in Visual Studio, where I connect to the correct IIS process - w3wp.exe with user name IIS APPPOOL\Dev or IIS APPPOOL\Prod according to the site I'm debugging.
Nevertheless I don't think the path should change itself. Where can be the problem? Does anyone have any idea how to prevent this strange behaviour?
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.
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.
I notice that there's frequently an aspnet_client folder under the standard IIS web folder structure. What is this used for? Is it needed?
In the .NET 1.1 days and before, this folder provided ASP.NET with its JavaScript support for the validation controls and other functionality. If you don't have a .NET 1.1 site or older running it should be safe to delete it. I would rename it first to ensure it doesn't cause any problems.
In addition to what others have said, it's usually created by the aspnet_regiis tool, which can be (re-)run by things like Windows Update/AddRemove Windows components/IIS. So sometimes even if you do delete it, it can come back randomly. There may be a way to stop this behavior, but I haven't found it (maybe changing the application version to .NET 2 would do it actually).
So unless you're using certain features of .NET 1.0/1.1 (validation, Smart Navigation etc) you can delete it without any problems, just don't be too surprised if it comes back!
aspnet_client is a folder for "resources which must be served via HTTP, but are installed on a per-server basis, rather than a per-application basis".
Some of the uses of aspnet_client include storing resources (eg. JavaScript, images) for:
JavaScript for ASP.NET Web Forms controls when using client-side validation (mainly to manhandle older browsers like IE5, it seems)
ASP.NET 2.0 (until at framework 4.0) for 'Global Themes' (global to all sites on a server, that is)
some versions of Crystal Reports
There probably are/will-be further (ab)uses of this folder in the future. Needless to say, since it contains things which are "necessary for the application to run correctly" but which "are not supposed to be deployed by the application", it will remain something of a nightmare for both developers and system administrators.
It seems that the 'prototype' for the contents of the folder is in C:\inetpub\wwwroot, and it seems reasonable to suppose that if any given IIS website lacks a /aspnet_client resource, then IIS will try to do the right thing and ... as a last resort ... make a physical folder in the web site root folder, and copy the files there. It seems that IIS will do this at least when "ASPNET_regiis /c" is invoked a given server - which probably occurs automatically at some critical junctures ... like when .NET framework updates are applied to a server which has the IIS role.
Strategies for handling the aspnet_client directory include:
specifying a virtual directory mapped to C:\inetpub\wwwroot in the hope that IIS will forgo creating a physical directory
deleting the physical directory from time to time if you're sure your site doesn't need it and it really bothers you
ignoring aspnet_client
running "ASPNET_regiis /c" yourself if you're missing the folder, and need it
Probably most importantly, as a developer, you should clearly understand and document your applications' dependencies on the aspnet_client directory, and make sure that your installation procedure has relevant instructions for making sure that the directory exists. However, you should probably not bother to actually supply the directory as part of your packaged web application or web site - how could you possibly do this for each version of the .NET framework which the server will see over the lifetime of your application?!
Some links I will come back to later:
http://my.safaribooksonline.com/book/certification/mcts/9780735657489/2dot-using-master-pages-themes-and-caching/ch02s03_html?query=((aspnet_client))&reader=html&imagepage=#snippet
What is the aspnet_client folder in my ASP.NET website?
iis express path for global theme directory
http://my.safaribooksonline.com/book/web-development/microsoft-aspdotnet/0735621772/aspdotnet-configuration/111?query=((aspnet_client))#X2ludGVybmFsX0J2ZGVwRmxhc2hSZWFkZXI/eG1saWQ9MDczNTYyMTc3Mi8xMTE=
http://my.safaribooksonline.com/book/web-development/microsoft-aspdotnet/9780471785989/working-with-themes/ch41lev1sec8?query=((aspnet_client))&reader=html&imagepage=#X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTk3ODA0NzE3ODU5ODklMkZjaDQxbGV2MnNlYzEwJnF1ZXJ5PSgoYXNwbmV0X2NsaWVudCkp
http://my.safaribooksonline.com/book/web-development/microsoft-aspdotnet/067232542x/performing-form-validation-with-validation-controls/ch03lev1sec1?query=((aspnet_client))&reader=html&imagepage=#snippet
http://scn.sap.com/thread/3157366
It also has certain icons and scripts that are required for crystal reports to run properly even in versions later than 1.1
The folder is usually for storing client side Javascript, which ASP.NET uses for things like validation.
It should be safe to delete.
Figured I'd add this here as this is the link I kept being directed to when I googled this question. Apparently with .NET 4.0 and newer this folder is no longer needed and can be removed without issue.
If you are using Installshield to configure ASP.net website, be aware that this feature was present in Installshield 2010 and is missing in Installshield 2012.