I am developing Excel add-in and use MEF to provide extensibility. DirectoryCatalog works fine on my local drive, however when I deploy solution to the network drive composition silently fails.
In regular .exe application this problem can be resolved by adding "loadFromExternalSources=true" to "runtime" section of application configuration file, however for Excel add-in this file does not exist (and I can't add Excel.exe.config to the folder, containing Excel executable since this folder is read-only). Is there any way to programmatically enable loadFromExternalSources behavior?
Is there any way to programmatically enable loadFromExternalSources behavior?
If you create a seperate AppDomain with AppDomain.CreateDomain, then you can pass a AppDomainSetup which has a ConfigurationFile property.
However, I suppose that comvisible objects are normally created in the default appdomain so making the new AppDomain talk to Excel will probably be difficult. I guess it would involve shim classes in the default appdomain which pass calls through to the other appdomain.
Related
I am trying to find out how to host an ISAPI DLL in Azure. In addition to the DLL, I'll need to deploy supporting files in subdirectories (javascript & css files). And two of these subdirectories can have their contents changed by requests handled by the DLL, so I need to ensure that the account executing the extension has write permission for these.
It would seem that the key to all of this is using a startup task to call appcmd to script all the IIS changes somehow, and I think I need to do the following:-
Deploy my ISAPI DLL and supporting files with my ASP.NET website
Create a startup task which will call a batch file utilizing appcmd.exe to do the following:-
Create a dedicated app pool with its managed pipeline mode set to Classic, and using a known user account
Create an IIS application pointing to the directory where my ISAPI dll resides
Ensure the application is configured to allow unknown ISAPI extensions
Alter the permissions of the required subdirectories so the user account associated with the app pool has write access
I've only just started exploring Azure, so my experience with it is very thin on the ground. Is what I'm hoping to achieve actually achievable? And if so, am I on the right track with regards to the steps required? They mimic what I need to do if I'm setting up this ISAPI DLL in the traditional IIS environment I'm used to dealing with, but please let me know if the rules are different with Azure.
Looks like a good sequence, however, the startup tasks actually run before IIS is completely configured. The 'OnStart' event in the RoleEntryPoint is called after IIS is set up, so it's probably easier to use the IIS application that Azure creates for you, and reconfigure it to include your ISAPI stuff.
Well the only thing bothering me here is that you're modifying data on the 'deployment drive' (E: for that matter). You shouldn't be doing this.
Instead, think of an other solution. You could create a LocalResource holding your javascript and CSS files. Then, when your role starts (Richard has a valid point about startup tasks), use ServerManager class to do the following:
Register the ISAPI dll
Add 2 virtual directories under the website created by Azure and point them to the LocalResource.
Modify the code of your ISAPI dll to modify JS/CSS files in the LocalResource
When developing in Web/WorkerRoles, you need to keep in mind that you should only manipulate files in a LocalResource.
On a project I am working on, we usually keep our application settings defined in a separate file. This is how it has been done for many years, and going forward we would like to keep all system configurations in one file. I was considering to use the web.config section so I can just load the configurations that I need from my C# code running on the server using the ConfigurationManager class.
If I use our own way for the application settings, I would load it in a session and have it available for the application by loading values from the session. After some reading online it looks like some of the performance issues behind using the session is that we have to deserialize the values from the session object.
Does IIS deserialize the web.config values each time we read values using the ConfigurationManager?
Thank you,
Vijay Selvaraj
Web.config is read once upon loading of the AppDomain. It is refreshed if any changes are made to it or any referenced files (you can put sections into external files by using the configsection= attribute on a section)
No, configuration sections are deserialized into the custom classes that reflect them only when the configuration file is re-read (such as when the app pool is recycled, a change to web.config is detected, and a couple of other conditions).
See also this question.
I created my custom assembly that has a simple HttpModule in it that I'd like to use in my Sharepojnt 2010 site.
I added my module to sharepoint site's web.config/system.webServer/modules section.
I then also copied my DLL directly to bin folder since that's how suual asp.net applications work. I got an exception about failed AspNetHostingPermission.
I copied the same DLL to _app_bin folder and it worked. My module did get initialized and was running.
I then added two permissions to my module class:
[AspNetHostingPermission(SecurityAction.InheritanceDemand, Level = AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.LinkDemand, Level = AspNetHostingPermissionLevel.Minimal)]
and also added these two to assembly
[assembly: SecurityPermission(SecurityAction.RequestMinimum, Execution = true)]
[assembly: AllowPartiallyTrustedCallers]
and strongly signed my assembly with a key I created.
Then I copied the DLL back to bin but it still didn't work. Copying it to _app_bin worked.
What do I have to do, to deploy my DLL directly to bin folder?
The problem you're running into is that SharePoint is using Code Access Security (CAS) to make it possible for really well educated Admins to make sure that they don't put their environment to unnecisary risk when adding functionallity to it.
The problem is then that even though CAS has been in .Net since the beginning nearly nobody has used it before SharePoint, so most developers don't know how to deal with it.
Everything in _app_bin is running with full trust, which explains why your dll works there.
Everything in bin is running with a lot less trust depending on the trust level specified in web.config (in fact this is also the one that specifies _app_bin has full trust, but thats common in all of the out of box trust levels).
In order to get your dll to work from bin (without changing trust level to full which is bad) you need to modify the policy file which the trust level is pointing to with the right xml for the right your dll need.
Adding the attributes don't help you directly, initially they in fact just makes the problem worse, because now your dll demands the rights even though it might not call anything which requires them.
Where the attributes help you is if you use WSPBuilder to build your WSP package for deploying to SharePoint (You're using a WSP right), then it'll look for security attributes and make the corresponding entries in manifest.xml which then get SharePoint to add the corresponding entries to the policy file on deployment.
In order for you attributes to work with WSPBuilder I think they have to be changed to SecurityAction.Demand though.
I am using SubSonic Active Record in a C# web application. I followed all the setup instructions and went well. i queried the database for some simple results and presto I got data. I then changed the namespace in the settings file right clicked on the ActiveRecord file and everything broke. Since then any classes and namespace generated in the ActiveRecord.cs file is not included in the project. Its like the file and the code inside ActiveRecord.cs do not exist or visual studio cannot process or recognize the files. I inspected the file and all seems well.
I am using TFS2008 if that may be the cause. I did notice earlier I also had an issue with System.Data if I pressed System. no Data namespace? This subsequently fixed itself somehow? and now I'm left trying to access the SubSonic generated classes and namespace.
Any ideas?
tks Hans
You have to make sure your project file is checked out - probably solution file too. TFS locks these things and you can't add files in unless the mechanism (your proj file) is unlocked.
As stated here custom field types (and any dlls they have a reference to?) must be deployed to the global assembly cache. Why, and what problems may arise by deploying to the bin directory? I’m trying to secure my code by writing CAS-policies and since my field controls uses a lot of help methods shared by my other code this seems like a show stopper.
So far the only problem I’ve found with a bin deployment is that when the feature is deactivated and then reactivated with STSADM I get an error message stating that my field type is not installed properly. Using the –force switch or activating through the GUI seems to be working just fine.
custom fields are installed farm wide, if you deploy the dll to the bin directory, you must ensure that they are in all web application's bin directories.
I forgot to put one of the interfaces my field type implemented in the GAC, which caused the problem I described above.
Conclusion:
Custom field types can reference dll:s in the bin directory, as long as they are not required to create the object.