Does SPMonitoreScope have any performance implication? I mean, can I leave the SPMonitored scope in production environment? or is it better practice to remove this from code?
Many Thanks,
Joseph,
Here's what MSDN says - http://msdn.microsoft.com/en-us/library/ff512758.aspx
Performance Considerations
Using SPMonitoredScope to wrap code has a very low performance hit. However, it should be noted that if a section of code wrapped by SPMonitoredScope were to contain a loop that performed a high number of iterations (for example, iterating through XML nodes that are returned by a SharePoint Foundation 2010 Web service), the call stack included on the Developer Dashboard could increase in size exponentially, making it difficult to decipher the information displayed.
Best Practices
A tip for the best and most effective use of SPMonitoredScope:
All calls to external components, such as custom databases, external Web services, and so on, should be wrapped with SPMonitoredScope. This will make it easier for administrators to identify them as points of failure, and to isolate the problem quickly.
Regards,
Nitin Rastogi
There is certainly a performance hit using monitored scopes. That being said, it's relatively small for the tyoe of work it does. Best practice is to switch it off on production environments unless you are investigating a specific issue.
Related
this is kind of an open question: I'm trying to define for a team a set of recommended practices for delivering a SharePoint solution in stages. That means, changes will happen at every level (solution, feature, web part, content types, etc).
On your experience, which are the practices that really, really, worked for you guys? For ex. using upgrade custom actions, placing upgrade logic entirely on FeatureUprading event handlers? Or in FeatureActiving handlers and assume features could already exist? Else?
I'm asking because I know of projects that follow The Word on this from many MSDN articles and still, upgrades are kind of nightmarish to manage, and those processes are sometimes difficult to grasp for average devs.
Thanks!
As no one else has ventured an answer, my current approach is:
Use the declarative approach for those cases where it works 100% of the time e.g. NOT content types
Fall back to code for the rest
Always write the related code so that it can be run multiple times against either the pre- or post-upgrade state
I am learning SharePoint and the different kind of solutions you can deploy. From the training I am watching it seems like you should try your best to use a Sandbox Solution when ever possible. This is because Farm Solutions can mess things up too much.
However, two of the main things I would do with WebParts are not supported in Sandbox Solutions. Those are Visual WebParts and WebPart communication. (The first is not allowed because it needs to hit the file system and the second is disallowed because it uses reflection).
It seems to me that my WebParts will always want to do at least one of those things. (WebParts that don't communicate are not really that modular are they?)
Am I missing the point or are Sandbox Solutions a "nice idea" that are not really used in actual code?
Yes, I agree with you that Sandbox solutions are very restrictive.
But, it is that restriction that gives them their value. Due to the restrictions a Sandboxed solution cannot bring down a farm (atleast that is the theory, someone may find a way to do it).
This means that you can open up to many more users to deploy things on the farm. It is also a requirement to deploy things to SharePoint Online.
That Sandbox solutions are more restrictive, means that development is more cumbersome, you have to program your way around the restrictions. This makes solutions more expensive. Therefore, the default should be farm unless you have a good reason not to use it.
I think some of the comments here are missing the entire point of a Sandbox solution, they have been deliberately given a reduced set of privileges for many reasons:
a) A site collection administrator can add a SB solution hence they need not be farm admins therefore better security of the farm.
b) You can trust that an SB will NOT bring down the farm, they don't even run under the normal SharePoint worker process, instead they are hosted under their own process that acts as a host to check to see if the resources accessed are allowed for an SB solution.
c) The cloud is coming, there’s no getting away from that fact, when somebody else is hosting your SharePoint solution do you really think you'll get access to the farm?
I think understanding the impact of running as a Sandbox Solution from a non-developer perspective is important, after all you wouldn't create a custom solution of any kind and expect the customer to grant you domain level accounts to run it, therefore when creating SharePoint solutions, think running your solution with the minimal amount of permissions by default, if there is really no other way then explore farm solutions.
Here's a useful guide from MS:
http://msdn.microsoft.com/en-us/library/ff798382.aspx
If your environment allows you to install farm solutions, then yes, sandboxed solutions are restrictive and stop you doing what you want.
However, if your environment does not allow regular solution deployment, as is the case with shared hosting and some large corporates then they are not restrictive because without them you wouldn't be able to use custom code at all.
Sandbox is horrible, i totally disagree with the statement "it is that restriction that gives them their value". you cannot do a many thing in sandbox.
1. no session
2. no web-part communication
3. no file upload controls
4. no redirect...
and it just makes things painful as hell. we are in the midst of developing an enterprise application facing outside users, my advice, if you considering Sandbox for these purposes, i would say add 150% more time for your project just to deal with sandbox issues.
most people talk about benefits, but all the benefits are not really benefits.. for example, if even a single sandbox application code raises exception which is unhandled... good luck, it will crash the entire farm, and tracking the issue is real nightmare.
if you can stay out of sandbox
Is there a way of offering the flexibility of Excel/Access development that end users love while instilling centralised IT management so data and logic is secure, backed up, version controlled etc. The common options are to re-write in C#/ASP.Net/Java/Python/Your Choice, but that takes away control from the users. Is there a better way, and what do you do at your site?
There is a universal issue of users creating fantastically useful Excel/Access mini-apps that the IT department would like to bring under control. Users love the flexibility that Excel affords, especially on the fly changes, graphing and data import/export. In Access we have brilliant QBE. The downside is that after a short while there are legions of out of control spreadsheets/mdbs which are mission critical, with lots poorly understood business logic, and brittle code, they're a pain to support especially as staff move on.
This puts the IT dept in an awkward spot, they'd like to support these apps, but don't know enough about them. This is made more difficult as they are typically insecure with zero documentation.
Having been of both sides of the fence I would go after the root cause of the problem. Why do uses make their own little apps? Because it is too hard/expensive/time consuming/never turns out right when they go through the “proper” channels.
The other thing is they tend to know the business very well so whilst their coding might not be very good their knowledge of what needs doing is very good.
So what can we do to combat this problem? I personally think their should be a small team of people within IT whose job (or one of their jobs) is to develop these small applications. They should work very closely with the end users and not be locked in the ivory tower of IT.
In my current role I’m on the non-IT side of the fence, I have a few quite major applications that needed to be developed so I asked for an install of visual studio and some space on an SQL server. I had my request denied. So I just asked for SQL server space, again request denied (each request taking about a week to go through) So in the end I’m “stuck” in access.
Now these are very nice access apps with version control, comments in the (shock!) and all the other nice things but at the end of the day I was trying to do things the “right” way and ended up being forced down the access route. So when my apps try to get scaled up and I’m quoting a long time for a rewrite who is to blame?
Have you considered looking at SharePoint for department-level applications? Many professional developers will balk at the idea of using Sharepoint for "application development," but it truthfully can be a great way for "power users" to start putting their data and tools in a managed framework.
With SharePoint, you can manage the overall structure of the site and then set up users with elevated permissions within their respective departments. There are some great 3rd-party tools to help with keeping an eye on what's going on in your SharePoint site.
SharePoint is not a silver bullet by any means, but it is great for many multi-user applicatinos that need to keep up with a list of data.
(The following is not really related to my above answer, but your question really hit home and I thought I'd share my similar experiences and insights.)
Our company will be going through a similar process in the near future. I'm on the "end user" side of things and can sympathize with a lot of what Kevin Ross said. Sometimes Access and Excel are simply the best tools available for me to get the job done.
Here's an example: I was asked several years ago to come up with a system for creating Purchase Orders to a vendor in China for product for which there is a 3 month lead time. Our ERP software had a few features for procurement, but nothing that even came close to the complexity of the situation we were facing. Years later, after going through several iterations of the application in Excel (VLOOKUP was a lifesaver), Access ("So that is why people using relational databases. Awesome!), and back in Excel ("let's not make this so complicated"), I still find that these Micorosft Office apps are the best tools to get the job done.
What's the cost to not use these tools to get the job done?
Contract work to our ERP vendor to add a special feature for this ordering process: are you kidding me? We'd likely pay tens of thousands of dollars for an unflexible monolithic application with horrendous user experience...and we would still end up back in Excel.
Buy third party software designed for this exact process: I've seen an on-site demo of software that does exactly what I want for our procurement process. It starts at $100,000. There are probably other tools that we can get for a few thousand dollars, but at that price point, I've already emulated most of their features in my own application.
Try to finish the job "by hand." : Ha! I'm a programmer at heart, which means I'm lazy. If it takes a solid week of sitting at a desk to work up a purchase order (it actually did take this long), you can bet I'm going to work up a solution so that it only takes me a few hours (and now it does). Perhaps the guy after me will go back to doing most of it by hand, but I'll use the tools in my toolbox to save myself time and stress.
It's so hard to find the perfect application to allow for maximum creativity on the user end but still allow IT to "manage" it. Once you think you've found a solution for one thing, you realize it doesn't do something else. Can I write I printable report in this solution like I used to do in Access? Can I write complicated Excel formulas that tie multiple data sources together from different sheets ("You want me to learn what? No, I've never heard of a "SQuirreL query" before. VLOOKUP is just fine thankyouvermuch)? Can I e-mail the results to the people in my department? Can it automatically pull data from our back-end database like I do in Excel and Access? Can I write my own code, VBA or otherwise, to make my job easier? The list goes on.
In the end, the best advice I can give to any IT manager in your situation is to respect the other workers at your company. Let them know their work is important (even if it's only useful to them and the guy at the next desk over). Let them know you are not trying to make their job harder. Don't assume they are morons for creating mission-critical applications in office productivity software; they are just trying to get the job done with the tools at hand and are usually quite capable and intelligent people. Invite them to explore different solutions with you instead of just removing the tools they currently have in their toolbox and then replacing them with ones they don't know how to use.
At the end of the day, if you have users who are smart enough to shoot themselves in the foot by creating complicated apps in Excel and Access, they are probably smart enough to learn to use the appropriate tools to accomplish the same tasks. Invest the time and energy to involve them in the process and you will have a solution that works for everyone at the end.
You could try a hybrid approach: Allow your users to use Excel/Access to home-brew their own, specialized tools, but take the mission-critical stuff and put it under IT control. There are a few strategies that could help you with this:
Make sure that your IT department is firm on VBA. Not the "yeah-everybody-can-write-a-few-lines-of-basic" type of knowledge, but in-depth training, just like you would if it were a less simple programming language. Although "real programmers" will tell you otherwise, it is possible to write large, stable applications in VBA.
If you currently have the data in Access databases, move away from that and migrate it to an SQL Server. This allows you to do centralized backup and management, while still giving your power users the flexibility to "link" these SQL Server tables to their Access frontend.
Commonly used business logic should be under control of your IT department. This can be done either with VBA, by creating an Access library that is linked by your users, or in any of the .net languages, using COM interop. The latter sounds more complicated than it is, and it will increase the satisfaction of your IT department, since developing in .net is just much more rewarding than VBA (version control possible, etc.).
I would second one of Kevin Ross's main points:
I personally think their should be a
small team of people within IT whose
job (or one of their jobs) is to
develop these small applications. They
should work very closely with the end
users and not be locked in the ivory
tower of IT.
I think any IT department that has a lot of users using Access/Excel should have at least one properly trained and experienced specialist in developing apps on those platforms. That person would be the go-between to make sure that:
IT's priorities and policies get properly implemented in the home-grown apps.
the end users get expert help in converting their home-grown efforts into something more stable and well-designed.
I would second Tony's point that whoever works with the end users in revising these apps to meet IT standards should work side-by-side with the users. The Access/Excel specialist should be an advocate for the end users, but also for the IT policies that have to be followed.
I also think that an IT department could have a specialist or two on staff, but should also have a full-time professional Access and/or Excel developer as a consultant, since the on-staff people could probably handle day-to-day issues and management of the apps, while the professional consultant could be called in for planning and architecture and for the implementation of more complex feature sets.
But all of that would depend on the size of the organization and the number of apps involved. I don't know that it would be desirable to have someone on salary who is nothing but an Access/Excel specialist, precisely because of the problem you get with all salaried employees compared to consultants -- the employees don't see as wide a variety of situations as an active consultant with the same specialization is likely to see and thus the consultant is going to have broader experience.
Of course, I recognize that many companies do not like to outsource anything, or not something that important. I think that's unwise, but then again, I'm the person that gets hired by the people who decide to do it!
If it's mission critical, and it's in Access or Excel, is built poorly, and no one understands it, it is probably time to rebuild it properly.
When the 'users' are in control it usual means one particular person is in control of the architecture, design, coding and documentation... except they normally omit the documentation step. Source control and bug reporting, the touchstone of software development, is usually absent. Few instances of code reuse, due to the nature of Office apps (code modules usually embedded into documents) and VBA (little OOP, most VBA coders don't use Implements, etc). All this means that the resulting applications are not subject to get proper scrutiny and quality can suffer, meaning there are likely to be maintenace issues, escpecially when that one user leaves. I know because I used to be that person ;)
So in order to satisfy the IT department, the proper process needs to be applied. That one 'power' user can continue to own the design and coding but will get peer review, perhaps the serivces of a technical author and a dedicated tester, be required to use source control, perhaps consider integrating with enterprise systems, etc.
There is no getting around the use of Excel/Access. It's what's available, and still very powerful and flexible. The best thing to do is offer some guidelines as to how files should look and be set up. If everyone is using similar standards then the files will live longer and more productive lives, beyond the creator's tenure at the company.
You've got some excellent answers regarding dealing with the folks and the business side of things. So my response will be more technical.
If you are going to redesign the app have the developers work in the same offices as the users. Given the users updates every day or two. If the users have any minor suggestions give those to the users within a day or two. Ultra Frequent Application Deployment
Give the power users an Access MDB/ACCDB linked to the tables with a bunch of starter queries. Let them create the queries they need to export the data to Excel for their own purposes and distribution to clients.
I’ve been working on a few small scale Access projects that have turned large scale rather quickly. The original designer implemented next to zero security and everyone can just walk in with a simple shift enter, way beyond just a security hole for nuclear submarines to dive through and that has always drove me bonkers.
With that said, users are currently on Office 2000, migrating slowly into 2003. I have taken this opportunity to convince higher parties to implement said security through the use of built in access tools.
Next I get to go through hundreds of functions and forms to pop in option explicit to define all the data types restricting the compile to MDE and clean up memory that was not done for some reason. There are some sensitive connection strings in the code that are plain as day that need to be compiled to reduce the risk factor.
My questions involve both the upgrade to 2003+ and the built in security. And yes, this is what I'm stuck with using unless I really want to redo everything in Visual FoxPro but building a porsche with rocks... not my idea of a good time.
When moving into office 2007, are
there any major holes that I should
be working around ahead of time?
Within the next year and a half the
whole business is supposedly
upgrading to this and I’ve only heard
horror stories about changed/obsolete
functions
Are there any major bugs that
can/will happen because of the use of
the workgroup file and permissions?
Tricks I should know ahead of time if
something crazy happens to lock
everyone out of it?
In the sandbox, I have not implemented the Encryption feature. Pros/Cons, Risks?
Any other good tips? I realize the broadness of this question and have a few good books on hand here (Professional Access 2000 Programming, Access Developers 2002, Developing Solutions with Office 2000 Components and VBA) but obviously these are before the time of current Access and Jet technology. If anything, a good book recommendation would be a booster for me, anything to give me a head start. Right now I really need to devour this security issue, its beyond just out of hand considering the sensitivity of the information at hand.
Thanks for reading my dreaded wall of text o.O
User level security does not exist for Access 2007 files (http://office.microsoft.com/en-us/access/HA101662271033.aspx). If the data is very sensitive, you may wish to consider a different back-end.
If the data is truly that sensitive it shouldn't be stored in an Access database file. Anyone can copy the entire data MDB/ACCDB and take it home with them to analyze at their leisure. Instead the data should be upsized to a database engine such as SQL Server.
Keep the current Access queries, forms and reports but get the data into a format that isn't so easy to steal.
Then think about limiting their views, logging the queries they run and such.
I would wait until A2010 is out before making any determination about upgrades beyond A2003. A2003 is fine for now, seems to me. I certainly wouldn't want to wade into targetting development to A2007 with A2010 coming out so soon and having so many really great new features (table-level data macros, really useful additions to Sharepoint integration that make a lot of really huge things possible, to name just two). My plan is to skip A2007 with clients (though I have it installed now and am playing with it so that I'll be better prepared when 2010 comes out).
One thing that doesn't often get mentioned about A2007 is that the Office FileSearch object was removed in Office 2007. If your app uses it, you can use my File Search class module to replace it. I've had it in production use since June (when I created it), but just released it more widely and am currently troubleshooting some issues that seem to be related to file names with odd characters.
Anyone have suggestions for security auditing of an .NET Web Application?
I'm interested in all options. I'd like to be able to have something agnostically probe my application for security risks.
EDIT:
To clarify, the system has been designed with security in mind. The environment has been setup with security in mind. I want an independent measure of security, other than - 'yeah it's secure'... The cost of having someone audit 1M+ lines of code is probably more expensive than the development. It looks like there really isn't a good automated/inexpensive approach to this yet. Thanks for your suggestions.
The point of an audit would be to independently verify the security that was implemented by the team.
BTW - there are several automated hack/probe tools to probe applications/web servers, but i'm a bit concerned about whether they are worms or not...
Best Thing to do:
Hiring a security guy for source code analysis
Second best thing to do hiring a security guy / pentesting company for black-box analysis
Following tools will help :
Static Analysis Tools Fortify / Ounce Labs - Code Review
Consider solutions such as HP WebInspects's secure object (VS.NET addon)
Buying a blackbox application scanner such as Netsparker, Appscan, WebInspect, Hailstorm, Acunetix or free version of Netsparker
Hiring some security specialist is so much better idea (will cost more though) because they won't only find injection and technical issues where an automated tool might find, they will also find all logical issues as well.
Anyone in your situation has the following options available:
Code Review,
Static Analysis of the code base using a tool,
Dynamic Analysis of the application at run time.
Mitchel has already pointed out the use of Fortify. In fact, Fortify has two products to cover the areas of static and dynamic analysis - SCA (static analysis tool, to be used in development) and PTA (that performs analysis of the application as test cases are executed during testing).
However, no tool is perfect and you can end up with false positives (fragments of your code base although not vulnerable will be flagged) and false negatives. Only a code review could solve such problems. Code reviews are expensive - not everyone in your organization would be capable of reviewing code with the eyes of a security expert.
To begin, with one can start with OWASP. Understanding the principles behind security is highly recommended before studying the OWASP Development Guide (3.0 is in draft; 2.0 can be considered stable). Finally, you can prepare to perform the first scan of your code base.
One of the first things that I have started to do with our internal application is use a tool such as Fortify that does a security analysis of your code base.
Otherwise, you might consider enlisting the services of a third-party company that specializes in security to have them test your application
Testing and static analysis is a very poor way to find security vulnerabilities, and is really a method of last resort if you haven't thought of security throughout the design and implementation process.
The problem is that you are now trying to enumerate all of the ways your application could fail, and deny those (by patching), rather than trying to specify what your application should do, and prevent everything that isn't that (by defensive programming). Since your application probably has infinite ways to go wrong and only a few things that it is meant to do, you should take an approach of 'deny by default' and allow only the good stuff.
Put it another way, it's easier and more effective to build in controls to prevent whole classes of typical vulnerabilities (for examples, see OWASP as mentioned in other answers) no matter how they may arise, than it is to go looking for which specific screwup some version of your code has. You should be trying to evidence the presence of good controls (which can be done), rather than the absence of bad stuff (which can't).
If you get somebody to review your design and security requirements (what exactly are you trying to protect against?), with full access to code and all details, that will be more valuable than some kind of black box test. Because if your design is wrong then it won't matter how well you implemented it.
We have used Telus to conduct Pen Testing for us a few times and have been impressed with the results.
May I recommend you contact Artec Group, Security Compass and Veracode and check out their offerings...