Is the source code for the common login controls available?
Those are the controls which are available under Login section in Toolbox:
Login,
LoginView,
PasswordRecovery,
LoginStatus,
LoginName,
CreateUserWizard,
ChangePassword
Eventually could you point me to a good source of custom implementation of functionality that those controls provide, or some guidance on implementing this functionality without using the mentioned controls.
I am using Visual Studio 2005 (.net2)
I will be using SQLMembershipProvider as the MembershipProvider but that probably should make no difference.
"the entire framework is available" is not true. :)
The source code for the entire framework is available. The link below provides some details as to how to access:
http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx
I am going to give this a qualified "NO".
I have gone down the road of implementing an implementation of the Login server control using reflected source as a starting point (this was before symbol server integration).
Things seem to go swimmingly, with a few reflection hacks to get to core framework members that obviate reams of code.
Until you get to the designers. That infrastructure is a minefield and gets wide and deep with a quickness and is filled with even deeper buried internal types that need implementations or reflection hacks.
Ultimately wound up with a working control that I could extend but would never want to maintain.
The effort was not wasted; I learned a lot about how over engineered server controls are designed.
And then I just shifted a login control to template mode and got everything I needed to get done in a few lines of code. ;-)
Except as a learning experience I would certainly recommend against going down that road.
Good luck.
Related
I'm trying to debug an ASP.NET MVC application which uses the .NET 4.5 version of WIF to provide user identity. As those claims are being generated by a remote STS specific for that user, it's hard to test which claims are being received for a given user in an development environment.
What I would like is a mechanism that will allow me to see a user's claims by looking over their shoulder as they use the system. I immediately thought of the ASP.NET WebForms trace system as a source of tracing information and a convenient mechanism to display it, but I don't know of an equivalent in ASP.NET MVC.
Are there any built-in mechanisms to expose this information to me whilst debugging with a tester?
Options
Glimpse- like webform inpage trage/trace.axd on steroids. Works nice for MVC apps, has little to offer webforms though (the team has been promising big things though, it's an area to watch).
trace.axd - Trace.Write output should appear here, I've never tried to run it on a busy server. Access to trace.axd should work for an mcv app, not sure if inpage trace works for mvc-- I would guess not but I have never tried.
<% "Some trace" %> -- I sometimes dump diagnostics to all screens and put it in the footer, or put it in the footer then make the text white on white, so I can instruct the user on how see it and copy it, but they won't normally see it.
System.Diagnostics TraceSource and associated classes -- It's better than Trace.Write but has some flaws if you use trace a lot. Still, there are scenarios when you can't assume your favorite trace/logging library will be available. If I were to use this, I'd write a custom listener and write to your user's diagnostic data to the database, or a file, listeners already exist for files.
Log4Net -- a trace/logging framework. Supports writing to a variety of places-- console, database, file, etc. Has fewer design flaws that System.Diagnostics, but requires adding noe more dependency to your app. Use same as System.Diagnostics -- log to a file or database and inspect your users STS values there.
I've never had the good fortune of using WIF or STS, but I imagine that pretty printing an object and it's properties is the same for much any object. You may want to post a WIF/STS question separately if you need to know how to extract a particular piece of info from it.
Well - Trace.Write data shows up in the output window in VS while debugging. Maybe thats good enough. You can also add a trace listener for the System.IdentityModel trace source to get more insight into the token/claims processing.
We’re currently evaluating development with Sitecore 6 for a project. The client already bought it, so using another CMS isn't an option. The proposed setup would have Sitecore as our site’s content data provider; which would be consumed by a site built in ASP.Net MVC 3. We’d use Sitecore’s libraries to retrieve data from the Sitecore database on the server side.
In some cases, we also may want to consume content data via client side AJAX calls. I’ve been working on prototypes for this to see what data I can get back from a custom proxy service. This service calls GetOuterXml on the item, converts the Xml to JSON, and sends back the JSON to the calling script. So far, I’m finding using this method limiting; as it appears GetOuterXml only returns fields and values for fields that were set on the specific item, ignoring the template’s standard value fields and their default values for example. I tried Item.Fields.ReadAll(), still wouldn’t return the standard values. Also, there are circular references in the Item graph (item.Fields[0].Item.Fields[0]...); which has made serialization quite difficult without having to write something totally custom.
Needless to say, I've been running into many roadblocks on my path down this particular road and am definitely leaning toward doing things the Sitecore way. However, my team really wants to use MVC for this project; so before I push back on this, I feel its my responsibility to do some due diligence and reach out to the community to see if anyone else has tried this.
So my question is, as a Sitecore developer, have you ever used Sitecore as purely a content data provider on the client-side and/or server-side? If you have, have you encountered similar issues and were you able to resolve them? I know by using Sitecore in this way; you lose a lot of features such as content routing/aliasing, OMS, the rendering and layout engine; among other features. I’m not saying we’re definitely going down this path, we’re just at the R&D phase of using Sitecore and determining how it would best be utilized by our team and our development practices. Any constructive input is greatly appreciated.
Cheers,
Frank
I don't have experience with trying to use Sitecore solely as a data provider, but my first reaction to what you're suggesting is DON'T!
Sitecore offers extremely rich functionality which is directly integrated into ASP.Net and configured from within the Sitecore UI. Stripping that off and rebuilding it in MVC is lnot so much reinventing the wheel as reinventing the car.
I think that in 6.4 you can use some MVC alongside Sitecore, so you may be able to provide a sop to your colleagues with that.
After reading the answer here, I understand that, if I register a user control (I guess I'm really trying to use it as a custom server control) like this:
<%# Register Assembly="MyDLL" Namespace="MyDLL" TagPrefix="myDLL" %>
Then only the codebehind is used, and the markup (.ascx) page is ignored. Why is this the case (it seems arbitrary), and how can I get around this problem without having to specify the Src="..." attribute in my Register directive? All I want to do is build a user control into a single assembly (a DLL) and hand that DLL off to another web site or web application project in such a way that the web site/app can use my user control. This should not be that hard, but apparently it is...
I am working in Visual Studio 2008, if it makes a difference.
Edit (prompted by the links in Rex's M's comments): it seems like most of the instructions for doing this kind of thing are applicable to VS2005, even the stuff on MSDN. My question is pretty much exactly stated here; is the answer provided on that thread correct
Is there any reliable, recent documentation describing this sort of thing for ASP.NET 3.5 and VS2008? I feel like using the latest versions is causing more confusion and difficulty than benefit.
The thread you linked to is indeed correct. The information which originally addressed .NET 2.0 and VS 2005 is still very applicable. .NET 3.5 does not actually change .NET 2.0, just adds extra stuff. For things that are already in .NET 2.0, they are unchanged in 3.5.
It sounds like you want the functionality of a Custom Control. In a normal user control situation, the website needs an .ascx and that cannot be placed in a DLL.
I strongly recommend to take a look at custom server controls. Since for the purpose of sharing controls over multiple projects they are better suited in my opinion than user-controls. User controls are better for internal reuse, within the same web application (i.e. on multiple pages).
This may sound a bit general, but I have a startup that is working on an ASP.NET (greenfield) suite of software applications. We are aiming to spend a substantial amount of time in the architecture phase to develop a strong foundation for our software. I was wondering if anyone has any advice, anything we should focus on or any suggestions for areas we should focus on to build a better suite.
Some things we are focusing on right now:
1. Session state requirements - should sessions be sticky or should we take server clustering session migration into account.
2. User login authentication - what are the major concerns in this space - LDAP, AD, custom SQL authentication systems etc.
3. The DAL - ORM vs Stored Proc
4. Integrating multiple ASP.NET applications in a single software suite. How it should look/feel. How it should be architected, etc.
I would appreciate any advice from any architects out there that have built similar systems from the ground up.
I know there are lots of solutions to session, but if you can create your framework to be session-free, you will avoid a lot of potential headaches. (There are lots of session-free options, but an obvious one is a hidden form field, somewhat like ViewState.)
Just some quick notes. I can't get too detailed since we went through this exercise where I worked last year - and I don't work there any more!
Start from the beginning using Enterprise Library, especially the Logging and Exception Handling application blocks. I've also found their Unity dependency injection library to be very useful.
Consider using Visual Studio Team Foundation Server. It's not just for source control, but can create you a complete continuous integration solution, complete with integrated bug tracking, code quality tracking, etc. If you've got the time and people, it's well worth a man-month to learn how to do an initial deployment.
You may want to buy one or more licenses of one of the Visual Studio Team System editions. You don't need these versions in order to use TFS, but they work well with it.
Consider globalization right from the start. Same with customization, if your suite will run on customer premises and be customizable by them.
You haven't said how large your team is, or is expected to be. If it's large enough, you'll want to spend at least a man-week learning a bit about what's available to you in terms of Visual Studio Extensibility. Your developers (and maybe also your QA folks) will all but live in Visual Studio, so the ability to customize it to meet your needs can be a big win. Whether it's just some macros and maybe some customized project or item templates, or whether you want to do add-ins or more, Visual Studio is very extensible.
Be certain to use WCF for any web services work. The older ASMX web service technology is now considered by Microsoft to be "legacy software".
Finally, be sure to find out whether you qualify for BizSpark, "A program that provides Software, Support and Visibility for Software Startups." And does so almost for free.
I saw a demo of Silverlight 3 at the PhillyDotNet User Group last night - WOW. Wow for business applications, not graphic applications. There is a learning curve, but you get a lot for it. For example, the demo showed a grid being bound to a table without needing to write any code.
Right out of the box you had sorting, editing, paging, etc. But it wasn't the lame stuff you normally get and then have to rework. For example the paging was smart enough to write the sql that would only bring back the 20 rows you needed for the page.
The demo continued with him putting a detail form on the page for editing. Again no code, but it was smart enough to know that it had the same datasource as the grid on the page. So as you were moving row to row on the grid - the detail form was showing the current row (and it was very fast).
Both the grid and the detail form were editable and as you changed a field in one the other would reflect the new value. The editing was smart enough to validate the field on its own. So you couldn't put a letter in a field that was an integer type, etc. It also limited the number of characters that could be entered based on the column size found in the database. All the date fields on the detail form automatically had a calendar next to them. You get the idea - no coding for any of this.
If this weren't enough, it can be used to build occasionally connected applications. So he showed how he updated a few records on a few different pages, had the option to revert back a field later (ctrl-Z), and then at the end submitted all the changed records to be saved.
Also, they said it works with Linq2SQL and the entity fraimwork.
So if I were building a new product now, I would really look into this as a way of differentiating my product. And I suspect that if you don't do it with Silverlight now, you will be rewriting it in a few years anyway.
Here is a link to a demo (not the one I saw.)
Some general thoughts. If you'd like me to expound on any of these, let me know.
Inheriting from a custom subclass of
Page instead of Page itself is a
great way to share functionality
across your site.
Nested MasterPages are good.
Charting: I've tried DevExpress,
Syncfusion, and MSChart control and
all have their own issues.
The built-in forms authentication is
pretty good. Building a site that
allows both integrated authentication
and forms authentication is tricky
but can be done.
I've tried using cross page postbacks
and I'm still not sure if I like
them.
Localization takes a lot of time
Come up with a good structure for your App_Themes and css.
Use Elmah to track unhandled exceptions
A little setup:
Our shop has a mixture of different platforms. Almost all of our web development is done in classic ASP. We have a WinForms application in development that is being written using the .NET 3.5 framework.
The problem:
I am writing a webservice for updating information to this enterprise application. Most of the classes and business logic also pertain to the WinForm application. On top of this, there needs to be a way to maintain some data on a website. Because we use classic ASP, I have decided upon using a generic HTTPHandler to make posts to. I use an ASMX webservice to query since I get XMLSerialization for free. However, I know this is not the normal use of a Handler and can't help but think there is a much better, short of converting a bunch of stuff over. Doing just this much is quite a bit more work than the project timelines allow. Can anyone offer some insight on this topic? More generally, how have people converted from classic ASP to ASP.NET? We are not a very large shop, so I think we're going to have to take it incrementally.
As a follow up to this question, I am finished with the roll out of this project and it is working pretty well. The AJAX portion was pretty easy doing it this way. However I never got ternary operators to work in my handler page and I'm not sure why. This resulted in first checking the HTTPContext to see if the control I was trying to read was actually there, and if it was, taking in the value from it. I suspect I did something wrong but for now I'll have to move on and refactor later.