Questions for CSharpHeaven:

Where does Microsoft admit that it was a "big mistake"? Link please.

YAF does have namespaces -- so I don't see how this argument holds water for YAF. If you are griping about most "Web Site" projects, understandable, but this doesn't apply to YAF.

I knew going Web Site was not necessarily going to be a popular decision with the more established programmers.

Main reasons: Every day someone is asking how to compile YAF. YAF is an international forum. A lot of people cannot afford to compile YAF using WAP because VS2005 PRO is required. Web site design is so much easier for modifications. It means that basic (literally) programmers can change a few variables here and there and change how YAF works.

Most of the libraries still require compilation -- but not Visual Studio Pro. The WAP project was included with the source distribution. Maybe I'll come up with a way to "have it both ways" here with some automated changes. For now, I'm chosen to support the majority over the knowledgeable minority who I figured could make it WAP if they wanted.

I'm open to further dialog on this topic though. Remember, I have very limited time and resources. If you give me solutions (auto-WAP project generation script), it would help. :)

I am a bit confused about this move to the ASPMembership provider. It looks like you guys took the 4 main tables from ASPNet, and made your own YAF-Aspnet membership provider.

I have a site that currently uses the default normal AspMemebership provider, and I Wanted to integrate yaf into my site. Now do I have to redo my application to use the YAF provider? Or can I change the provider YAF uses with minimal code.

Why did you guys decide to go to the Asp membership route if you were just going to create your own provider anyway. I guess I don't understand what was gained.

Thanks for all your hard work, I got it installed and it looks great.

The default YAF Membership provider is mostly to allow for backwards (upgradability) from older versions of YAF -- which was not possible with the default asp.net membership.

Also, the YAF providers have built-in caching for speed.

Updated with most recent bug fixes as of 12/19/07.

Hi Jaben,

Where does Microsoft admit that it was a "big mistake"? Link please.

I knew that was coming. I'm sure I read about it on the blogs of the developers who work for Microsoft. They normally reflect what is going on inside of Microsoft. Also since i'm working on an add-in there are issues with the web site model that is not well supported and is difficult to work with. This is probably was behind what I said about the admitting part. In my project I gave up using the automation model that was offered for being too basic. I wasn’t trying to exaggerate about it mate.

YAF does have namespaces

I'm very happy with that. It would make the conversion much easier.

I'm open to further dialog on this topic though. Remember, I have very limited time and resources. If you give me solutions (auto-WAP project generation script), it would help.

Those who produce never have enough time. So I can say the same thing too. I only can try to see if I can come up with a generic solution when I have the time.

BTW, did you get my email that I sent to you a while back? I used the email being shown on your main site mate.

I appreciate the hard work you've been putting in this project.

I never got an email from you... Can you send again to support@yetanotherforum.net?

And seriously... I'd like to read any explainations about the Web Site problems. Maybe you read on Scott Gu's blog?

I never got an email from you... Can you send again to support@yetanotherforum.net?

And seriously... I'd like to read any explainations about the Web Site problems. Maybe you read on Scott Gu's blog?

I just re-sent the email to you. The original email was sent on 02/12/2007.

There is YAF provider, which is default. But as of nature of providers, you can replace it with your own provider (be it default ASPNET one or any other) and it all works without single change in the code.

Thanks I was able to get this to work very easily by changing the web.config. I still have to popular YAF's user table though. But no big deal. Thanks. After I perfect this I may submit what I did so others can do it also.

Great work on 1.9.3.

Maybe this is a stupid question regarding membership and roles (hopefully not). Can someone help me understand how user data will be stored in the YAF DB if a different membership provider is used? I have seen this topic posted numerous times, but would appreciate further direction.

My Problem:
- Existing users/registration/login (with SQL backend) in a separate web application (classic ASP).
- Want to use YAF forum, but use existing SQL user login in different DB than the YAF DB.
- Do not want to expose password retrieval or registration or profile update to users since user data will be stored in existing SQL DB.

Do I need to maintain user information in both DBs?

Hello Jaben,

You asked for pointers about Web Model / Web App: here is a link to a short entry with few interesting links...
I have to say that just like CSharpHeaven, I believe that VS2005 model is a mistake...

http://petesbloggerama.blogspot.com/2007/05/web-site-project-or-web-application.html 

Spi

Hello Jaben,

You asked for pointers about Web Model / Web App: here is a link to a short entry with few interesting links...
I have to say that just like CSharpHeaven, I believe that VS2005 model is a mistake...

http://petesbloggerama.blogspot.com/2007/05/web-site-project-or-web-application.html 

Spi

I hear ya -- but all of those arguments cannot go up against the big one: YAF main UI should be simple to modify. What do I say to people who cannot modify the basic UI because they don't have 600 USD to buy Visual Studio Pro? Plus, the project is NOT all Web Site -- most of the code isn't. Just the UI/Pages code -- which I feel is a decent trade-off.

Great work on 1.9.3.

Maybe this is a stupid question regarding membership and roles (hopefully not). Can someone help me understand how user data will be stored in the YAF DB if a different membership provider is used? I have seen this topic posted numerous times, but would appreciate further direction.

My Problem:
- Existing users/registration/login (with SQL backend) in a separate web application (classic ASP).
- Want to use YAF forum, but use existing SQL user login in different DB than the YAF DB.
- Do not want to expose password retrieval or registration or profile update to users since user data will be stored in existing SQL DB.

Do I need to maintain user information in both DBs?

YAF handles this fine. You don't have to maintain user information at all. Just point YAF to the other (already populated) membership provider.

YAF will just create users as needed in it's DB and will automatically sync with roles. No manual work...

Update with fixes such as the user suspend issue and RSS issue. (Plus all the other little bugs posted...)

Root Key in app.config now supports "~/forum" for the application root.

I'm on vacation next week so I won't be looking on the board much or working on YAF.

Happy Holidays to everyone.

Hello Jaben,

You asked for pointers about Web Model / Web App: here is a link to a short entry with few interesting links...
I have to say that just like CSharpHeaven, I believe that VS2005 model is a mistake...

http://petesbloggerama.blogspot.com/2007/05/web-site-project-or-web-application.html 

Spi

I hear ya -- but all of those arguments cannot go up against the big one: YAF main UI should be simple to modify. What do I say to people who cannot modify the basic UI because they don't have 600 USD to buy Visual Studio Pro? Plus, the project is NOT all Web Site -- most of the code isn't. Just the UI/Pages code -- which I feel is a decent trade-off.

I'm with Jaben on this one. Putting the core functionality in separate assemblies and the UI in a web site is just fine and will suit the most numbers of users, IMO. You can always precompile the site so you don't have to deploy the source files (Peter didn't mention that in his blog for some reason). You don't really unit-test the UI in a way that you'd care about the generated assemblies anyway. Also, you can simply drop YAFs pages in your own WAP and build. It's really no big deal. No need to exclude a large number of VWD users unless there's some tangible gain. And since MS uses the web site model in VWD2008, it's not going away any time soon.

I just downloaded 1.9.1 source, and installed Web Application Project (WAP) add-on to VS2005 Pro so I could open the solution (working in a corporate environment, I cannot install SP1 for VS2005 without forcing other developers to do the same). I am looking to deploy a forum on the company's intranet, which already requires the users to authenticate there. So it looks like I will want to download 1.9.3 to do this. Based on my initial, limited, experience with YAF, I have the following questions/comments:

1). Could Jaben or one of the other core developers take a few minutes to update the Roadmap on the Wiki? It still shows 1.9.3 as a Q3 2007, 1.9.5 as Q4 2007 etc. for projected release dates. Having accurate projected release dates and summary of proposed features/enhancements is helpful to anyone evaluating YAF and whether it does or will soon meet the needs of the person/company looking to use it.

2). Moving away from the WAP methodology not only benefits users the do not have VS2005 Pro, but also benefits folks in corporations that are not using VS2005 SP1. In my specific case, I have administrative rights to my machine and was able to download and install WAP myself. But some corporate environments could be so restrictive that even installing WAP to VS2005 might require going through a lengthy approval process. While 1.9.1 is still the offical release, could there be a note or disclaimer that WAP or VS2005 SP1 is required to properly work with the solution if you choose to download the source?

@ tempest68 and wesclyburn

I would suggest to google "Migrating a VS 2005 Web Site Project to VS 2005 Web Application" and see from the links how many people are writing articles on this subject. Also check how many people are writing about the pain is involved in the process. What that tells you?

If you can't install VS2005 SP1 within your organisation then should we all be affected by it?

I've been working to add features to my tool to ease up the migration part and on the first attempt I had to stop supporting "Web Site Project". Behind the scence "Web Site Model" is horrible and that only means this project type gives less productivity to its users, then again I hear people are insisting to switch a perfectly working model to something that doesn't work very well.