Adding Opportunities In MS CRM with Code!

Ok, in case anyone cares, I am now doing a LOT of custom dev with MS CRM 4.0. If you have a question, ask me. I have probably already done it!

Anyway, I'll try and share code snippets when I think about it. Here is how to create a new opportunity via code. You know, in case you have a dataset of leads and want to auto-magically create opportunities from it.

opportunity o = new opportunity();
o.name = "*NAME OF OPP*";
Customer c = new Customer();
c.type = EntityName.account.ToString();
c.Value = new Guid(*GUID of Account to tie it to*);
o.customerid = c;
//ADD any other data about the opp HERE!!
//Grab the new opportunities ID on create!
Guid gOpId = _Service.Create(o);

See? Easy!

SharePoint Is Awesome

So, there have been quite a few posts lately that trash SharePoint. The comments are along the lines of "it's too hard to install/ develop on" or "it's too complicated". To all the whiners out there all I have to say is $(%&P($#%(#$%#$(, sorry I mean suck it up. Geez! I mean you are working in TECHNOLOGY!!!!!! Hello!! The world changes, new technologies come and old ones go. SharePoint is the future of development for at least the next 5 years. Deal with it. I love this blog post in response to one of these boo-hooers:
http://tonybierman.com/blog/2007/10/16/i-dont-care-if-you-dont-want-to-develop-on-sharepoint-and-neither-does-your-boss

It really says it all. Especially this part:

"I don’t care if you don’t want to develop on SharePoint. In fact, neither does your boss. Because he’s going turn on SharePoint in your enterprise anyway, just like everybody else is. One billion in sales baby, and growing fast. And your boss is going to want customizations and apps written for SharePoint. If you can’t do it, your boss is going to find someone else to do it. Like me."

And from Bob Mixon:
http://bobmixon.com/BLOG/archive/2007/10/16/Are-You-Ready-For-SharePoint.aspx

Couldn't have said it better myself! If you think SharePoint is too hard/complicated/difficult then you probably shouldn't be working as a developer. Why dont you run on home and let the grown ups get back to work

MOSS Bug?

I'm working on an application and we are using User Controls hosted in an ASP.Net 2.0 Web Part. Everything was working fine then suddenly nothing seemed to work right. The form view controls were either outright broken, or the we saving blank rows to the database. It took some investigating, but here is what I discovered:

1. You cannot have an Object Data Source running on MOSS and it have a parameter (insert, update or otherwise) with a type of 'object'. This appears to be the type assigned for GUIDs (database fields of type 'unique identifier'). When you do, as soon as I would bind the formview I would get a generic MOSS error page. You know the one, 'A web part is causing a problem....'
By changing the type on the parameter to 'string' everything started working. Of course that was only half the problem. Since making this change eliminated the MOSS error but I was still getting blank rows in the database.

2. The other thing I discovered. You cannot use the asp:table control in templates of the form view. When you do, the data fields are no longer bound to the datasource. The asp:table is bound. The controls of the form view are now children of the asp:table and not the form view. You could probably get around this by fully qualifying the controls for the parameters but why?

So, we changed the templates back to straight HTML tables and changed the parameter types to strings and voila! The app is working as it should.

Now keep in mind that outside off MOSS the app worked fine without changing the parameter types. The asp:tables were still an issue thou.

Windows Auth + FBA

I have been working to implement Forms auth and Wndows AD together on the same web application for the last few days. I am pretty happy with the results (extending the app, creating an extranet zone etc.) but saw this great article and thought it would help a lot of you out (like Scot!). Here's a quick blurb:

"This method uses forms authentication on a SharePoint web application to authenticate users against both SQL Server and Active Directory. Not only will this hybrid provider be able to manage users across the two most prevalent user data stores in Windows, but it can also be scaled out to support other .NET membership providers, as well as run custom code to query into any source of user information."

Thanks go out to Christopher V Domino for the great article!

Workflows P2

So, I was working on a project and need to programatically fire off a work flow for a list item. Easy you say? Well it is. Sort of. See first I needed to know WHICH work flow to fire off (in case there were multiple workflows associated with the list). So here is the code I used:

private void GetWorkflows()
{
SPWeb web = new SPSite "http://serverurl").OpenWeb();
SPList list = web.Lists["list name"];

string strWorkFlows = "";

//This would normally be passed in. Its the List Item ID
string strTaskID = "4";

foreach (SPWorkflowAssociation wfa in list.WorkflowAssociations)
{
if (wfa.BaseTemplate.Name == "NameOfWorkflow")
{
strWorkFlows += wfa.InstantiationUrl + "?List=" + list.ID.ToString() + "&ID=" + strTaskID + "&TemplateID={" + wfa.ParentAssociationId.ToString() + "}&Source=" + list.DefaultViewUrl;
}
}

Neat huh? What I did was re-create the URL that exists when you initiate a workflow from the list itself. The 'BaseTemplate.Name' will give you the name of the workflow assigned in the feature, not the one assigned by whoever created the association. This is helpful for making sure you find the correct workflow. That's it. Ping me with any questions/thoughts/suggestions.

Setting the Content Type of a document programatically

I had occasion to write a workflow that collected some documents and uploaded them to a documnet library. Pretty easy task, however I hit a little snag. Each document had a unique content type depending on the type of document. How would one go about setting the content type of a document that was being added to a doc lib programatically I asked. It would make sense to do it like so:

SPContentType type = list.ContentTypes["[Enter Content Type ID]"];
file.Item.ContentType = type;
folder.Files.Add(file);
folder.Update();
list.Update();

Alas, no. You see file.Item.ContentType is READ ONLY. Hmmm, now what? Well answer was a little more obscure than I expected. But ironically was the same methode I was using for someting else. Here is the solution:

Hashtable fileProps = new Hashtable();
fileProps.Add("ContentType", fileDocType);

Where fileDocType is passed in as a string representing the name of the ContentType. I already had the Hashtable created to set some other metadata on the document, so I really only need one additional line of code. Neat huh?

Adding new Virtual Directories with code!!!

Ok, we had a question come up at the User Group (UG) the other night. This person needs to create new virtual directories each time a new site is created. These VirDirs are to host legacy ASP.net applications. Now I know the CORRECT answer (at least mine) is to not host other applications on your SharePoint FEWS. However in the interest of being fair and realizing that it may be the only option for some folks, here is some C# code you can use where appropriate:
=================
//Create New Virtual Directory in IIS with DirectoryEntry()
string wwwroot = "c:\\Inetpub\\wwwroot";
string virtualDirectoryName = "myNewApp";
string sitepath = "IIS://localhost/W3SVC/1/ROOT";
DirectoryEntry vRoot = new DirectoryEntry(sitepath);
DirectoryWntry vDir = vRoot.Children.Add(virtualDirectoryName, "IIsWebVirtualDir");
vDir.CommitChanges();
vDir.Properties["Path"].Value = wwwroot + "\\" + virtualDirectoryName;
vDir.Properties["DefaultDoc"].Value = "Default.aspx";
vDir.Properties["DirBrowseFlags"].Value = 2147483648;
vDir.Commitchanges();
vRoot.CommitChanges();
======================
Enjoy!