Finally, I've finished creating the Add-On that does exactly what I want in exactly the way I want. Only one issue remains. At the moment the software goes to organization and uses credential that are statically hard coded into the program.
I have a hunch that some of my customers might name their organization something else than "Hazaa Inc. #1-5", they could be called something else than "CRMK.local\Konrad" and there's a chance that they even choose a different password than me (although "abc123" is apparently fairly common).
So, here's the issue - how do I make my solution general?
I believe that as long as I get the right input to the code below, I'll be done.
using (OrganizationServiceProxy proxy
= new OrganizationServiceProxy(
organizationUri,
homeRealmUri,
credentials,
deviceCredentials))
The current log-in string I copied by hand from "Settings" in the CRM Dynamics but it won't suffice here. I need to obtain it dynamically and programmatically. Moreover, even if I learn the name of the organization, I need to determine if it's a CRM 4.0 or CRM 2011, if we're talking On-Line/Premiss what the user name and password are etc.
Is it a better solution to simply ask for that information to be provided by the user or would it be recommended to do that auto-magically (as far as the user experiences it)? This is my first time so most of stuff feels scary and confusing. I've seen some code examples but that led me back to scary & confused very quickly.
EDIT:
I've followed this code but I simply don't get it. E.g. ServerConnection I don't even know where to find. I tried adding references to the different Xrm and Crm packages in the SDK but it's more of a trial-and-horror than actual development. It feels like I'm missing something (fairly) obvious.
When in doubt, ask the user instead of trying to guess: you might unwillingly break something if your assumption is wrong.
Some more thoughts:
Online vs. On-Premise has limitations which might break functionalities. If you need things to work on both, focus on Online. In other words, if it works Online, it works On-Premise, but if it works On-Premise it might not work Online.
CRM 2011 provides many many innovations when compared to 4.0, code should really be branched so you stick to old-style in one project and leverage all the new features in another one. Solutions management alone is worth dropping 4.0 support altogether.
Related
I am making an webcrawler in C# which needs to find webshops. The problem i'm having is that I need to detect if the webpage is a webshop. If it is I need to find out what type of e-commerse software it is using. But the problem is that I don't know how you can detect it in the source code.
I also have just a Chrome plugin called builtwith which can detect all kinds of software. But I have yet to find out how they are doing that.
It would be nice if someone could help me with this problem
Before giving you an actual answer, it's worth noting that what you're proposing could be in violation of the terms of use for many websites out there. You should take the time to investigate what legal liability you might be exposing yourself and your organization to.
This is going to be a lot of time consuming work, but it's not difficult. Your crawler is just going to need to simply work using a rules-based approach to detect signatures in the payload of the page.
Find the specific software that you're intending to detect.
Find 2-3 sites that are definitely using the software.
Review the HTML payload to see what scripts, CSS, and HTML patterns they have that are common across the sites.
Build a code-based rule that can detect those patterns consistently. For example: if (html.Contains("widgetName")) isPlatformName = true;
Test that patterns across more sites that you know for certain are using that software.
Repeat for each software vendor.
The more complicated thing will be when the targets have multiple versions and you need to adapt your rules to know and be aware of the various versions, or when platforms are very similar.
I think the most complicated part of this is having a well-thought-out bot issue detection, reporting, and throttling architecture in place. You should probably spend the bulk of your time planning that.
That's it.
There are a couple different ways to determine the technologies a site is using. Firstly, if you are technically savvy, you can right click on an eCommerce page (either catalog, checkout page, etc) and look at the source code. Many platforms will have hints in the source code that will give you an idea what the site is running.
You can also look at the DNS/hosting information, which would help you determine if the eCommerce solution is hosted or SaaS (like Shopify, for example).
You can also try using InterNIC and enter the domain name. The results will return the nameservers which could point you in the right direction.
Finally, if all that sleuthing seems too difficult, there’s an easier way! Try BuiltWith. It’s generally pretty reliable, as long as the system you're looking up isn’t custom/proprietary. Enter a domain into BuiltWith and it will show you the platform, widgets used, analytics and tracking codes, CDNs, CMS, payment processors, and more.
I'm at a customer where I successfully developed and deployed a WCF service layer (compiled against .NET 4.5). It works perfectly and everything is dandy.
However, we just got an additional requirement - I'm supposed to rebuild (or at least redesign) the layer to incorporate WSSF. There's no old functionality that we'd need to integrate with and all operations in the services are based on executing SPs in a DB.
Should I do that or is it wiser to argue against it? I'm not certain because I've never worked using WSSF and I got virtually no explanation as to why we should at this particular workplace (which could be that they don't want us to know as well as that simply don't know themselves).
My worries are based on, but not limited to, the following.
The latest release is from August 2010.
There's nothing listed in documentation section.
The license seems to be in conflict with commercial activities.
WSSF isn't widely used as technology today (or is it?!).
The purpose of WSSF is to WCF-fy old service layer (or isn't it?!) only.
Especially #4 and #5 are not the strongest statements in my arsenal at the moment so I'll gladly stand corrected, should anybody have a few wise words to contribute with on the subject.
Short story is that it doesn't look good. From MSDN: Web Service Software Factory 2010:
The Web Service Software Factory is now maintained by the community
and can be found on the Service Factory site. This content is outdated
and is no longer being maintained. It is provided as a courtesy for
individuals who are still using these technologies. This page may
contain URLs that were valid when originally published, but now link
to sites or pages that no longer exist. Retired: November 2011
1) So, it looks like it's totally being run by the community. However, looking at the discussion forum there aren't many postings and quite a few have no responses.
2) I find it's fairly common for the documentation tab to be empty at codeplex but there is frequently documentation but not on the documentation tab.
3) In terms of licensing Ms-PL is quite permissive so I wouldn't imagine there would be any issues.
4) Not to belittle it but I don't think it was/is very popular. Definitely not a standard.
5) The intent of the service factory was to provide guidance -- both written and code based. See Web Service Software Factory for a discussion.
WSSF was a tool that incorporated best-practices for building WCF services. It's been years since I've used it, but basically I recall a wizard that asked several (actually lots of) questions about the service (contract), data (model), etc. What it would produce is a nicely organized solution with several projects with proper naming conventions, verbose declarations like adding IsOneWay=true/false to [OperationBehavior]'s or IsRequired=true/false, Order=n, etc. to [DataContract]. In other words, it generated very verbose code that most of us blow off until we need it.
It did more though, such as structuring your solution so that service contracts were in one project, data contracts in another, and implementation in yet another. It created test projects (I believe). so, very granular layout of the solution. I remember the simplest of services would result in about 6-7 projects in the solution. It was a little intimidating at first until you poked through the code it generated.
Another cool feature it had (at the time many were asking for) was a way to do contract first development. Given an existing web service metadata, you could constuct a new service solution.
Anyway, once it was completed, you just had to do essentially provide implementation for the methods. Personally, I never really embraced it for services development. But, at the time, I appreciated it and often referred customers to it who were new to services development because I knew it would get them off to a proper start.
To comment on your worries though...
That's correct, and it is not getting any resources to update it.
Actually, there is quite a bit of documentation. Just move over to the Home tab and you will see links to it.
Not sure about this. The code it generates is yours. You still have to compile it and it's yours to maintain going forward. No different than any other code-generation tool (as far as I know).
Nope, it is not. Also, consider the time when this was developed, .NET Framework 2 - 3.x. There's been a lot added to WCF since then. There's also been some new guidance on service development. If you're using some of the newer features added in .NET Framework 3.5SP and beyond (which you probably are), then this definitely is not something I would recommend using.
Again, that was one of the nice features (contract first development). But, that really wasn't the main idea. It was a tool to build out the framework for new services too. In fact, new service development was the original motivation of the tool as I recall. Once you took the time to go through the dialogs, you had a really nice solution to start building on.
I have a Vb.Net/C# 2010 project that I'd like to distribute as a setup file. During installation, it should ask the user for a serial number. Any suggestions as to how to do this?
Here is a question on DaniWeb, more an idea rather than an actual way to implement it: http://www.daniweb.com/forums/thread336128.html
Written in VB.NET, this person made a package of code that randomly generates CD keys. It might help with random generation in your project. He stated that he would try to get C# code up some time, but I don't know if he has or will. Here's the link: http://www.codeproject.com/KB/security/cdkeys.aspx
This thread has a couple of links to MSDN articles and some interesting ideas on the topic: http://www.vbforums.com/showthread.php?t=472626
As far as I can tell, if you sincerely want to implement a serial key system, you would:
1) Need to randomly generate keys and store them somewhere.
2) Check the available keys every time a user enters one, therefore requiring online access.
3) You might even have to use paid libraries, as it's difficult to do this alone.
4) Give the user some kind of offline "key-storage" technique, such as Autodesk products do. This means that they fill out the registration and then save a file to their hard drive with their registration information, so they can send it to you later, when they have an internet connection. Be warned, however, that these offline activation systems are very easily exploited.
I'm sorry I can't be of more help, I have researched this topic, but have never successfully accomplished it!
Good luck!
Either code everything yourself or i would say use an Installation Builder tool like Install Shield from Flexera Software which provide such facilities. Even Microsoft suggest it.. however its not free.
I will be taking on the role of support for a complex application that is transitioning from the development team. This application is a sharepoint solution that connects to several (7) web services. The development team is rolling off almost immediately and will be available only for small questions.
I'm new to this role so I'm wondering what suggestions you have for me as I take on this large project. What are some considerations that should be made so that the transition to support is smooth and uninterupted?
I've been reading the documentation but I can already see some gaps that need to be filled. The applicaiton is very (perhaps overly) configurable and there is lots of injected code. Stepping through the code is about the only way I can gain an understanding of what is actually happening.
It sounds like you've already got your environment set up if you're able to debug the application, so that's the first thing I was going to suggest in a knowledge-transfer situation. Some general things that I would get from the developers before they depart:
A list of third-party components that the application uses, along with license information and website logins if applicable.
Access to every part of the environment that this thing runs on, both production and development. That means the source code management system, database server(s), etc. It sounds like you have some of these already but make sure you get access to absolutely everything.
If your development environment was given to you "as is" (i.e. you took it over from one of the departing developers, make sure you know how to rebuild it from scratch. They might have a document that describes the process of building a development box, but if not maybe you can get them to show you how to set up a fresh machine.
Three will go a long way towards this, but if setting up a server to run the application is different in any way from setting up a development environment, you'd want to know how so you can diagnose server configuration issues if they crop up, or even rebuild a server. Although this sort of thing may be someone else's responsibility depending on your organization.
Once you have those, you probably want to get some understanding of why the application does the things that it does. That will give you the context you need to understand support and enhancement requests when they come in.
Are the original developers the only source of this information, or are there business people who you will be working with after the developers leave? One of the first things I try to do when starting on an existing application that's new to me is to find someone who knows the business well and have them give me a high-level run-down of the application's purpose in life. From there you can go into more detail on individual components/features/whatever as needed. The business people may be a better source for this information than the developers are, so you may want to try them first.
Hopefully some of that helps.
If you're not the systems admin (as opposed to the SharePoint admin), develop an understanding with them of what tasks you are able to do and what you need of them.
This may include things like stopping and starting services (IIS, Timer Service, etc.) and filesystem and DB monitoring and maintenance. Getting this sorted out up front saves a lot of pain later.
If the sys admins don't have some understanding of SharePoint, educate them. They will need to know what the deal is with things like code deployments.
It's best not to feel my pain.
I have just won 1 Telerik Premium Collection for .NET Developer with subscription (lucky me!) and was wondering whether the OpenAccess ORM is worth learning? Has anyone thrown away their open source variant and are now using the Telerik ORM tools instead?
Are there any benefits from using the Telerik ORM tools instead of an open source variant?
Any thought suggestions?
BTW I can't wait to start using their RadControls for ASP.NET AJAX!!
I'm a happy telerik customer for more than 5 years. I used their ORM only in one solution and never used an open source ORM.
Throw away the existing one?
NO - if you have no problems and the thing does what it should do I wouldn't change.
That has nothing to do with quality or other aspects of telerik ORM.
It's just a matter of fact that using a new product means to learn new things, solve some solved things again in a different way and so on.
BUT - if you have problems (or must make compromises) with your current product it's sure worth to give it a try.
Without knowing other ORMs I have one clear point why I would try telerik ORM.
It's their (telerik's) outstanding support.
None of my other vendors offers / does what telerik does.
Simply take a look at their forums http://www.telerik.com/community/forums.aspx and you'll see what I mean.
You have a problem - they solve it; and that with very fast response times.
And that's a point you should think about when making a decision about ORM (or any other kind of product).
This is an older post, but I thought I would weigh in.
We recently started using Telerik's SiteFinity product for a client website. It is a very good, developer-oriented tool for creating a web content system without the size or expense of SharePoint or something similar.
We also went with a Cloud solution as Telerik's ORM supports Azure, so thus so does SiteFinity - which uses OpenAccess (ORM) to communicate with its database.
I was very impressed with the speed and flexibility of it all, being my first Cloud (Azure) development project. Telerik's customer support and personal attention is beyond reproach. I have been using Telerik products for years and was not surprised how well it worked.
Two days before the site was to go live everything bombed with a very inexplicable .Net error. As it turns out Microsoft announced they were upgrading their Azure SQL servers starting July, 2011: "This upgrade is also significant in that it represents a big first step towards providing a common base and feature set between the cloud SQL Azure service and our upcoming release of SQL Server Code Name 'Denali'."
(http://blogs.msdn.com/b/windowsazure/archive/2011/07/13/announcing-sql-azure-july-2011-service-release.aspx)
By its very nature, Cloud servers are upgraded and moved around behind the scenes so you don't have to mess with it. OpenAccess failed to take this into account however, and when our SQL Azure server group was upgraded OpenAccess failed to recognize its version and bombed.
Telerik, of course, was very quick about releasing a patch - but it still took them a few days. We couldn't wait that long, unfortunately, having already lost quite a bit of time just trying to figure out what was going on. The practical result was that I got to work nonstop for two days with no sleep to move the whole thing into a regular .Net solution with Entity Framework 4 as the ORM.
So to answer the question: Is Telerik ORM worth learning and / or better than an open source solution? I agree with the above statement that if you already have an open source solution, it is working well, has good performance, and is intuitive to develop against - absolutely stick with that.
The value of open source is the community that supports it and your ability to make changes to the underlying system if need be. Had my project been based on an open source ORM, I could have changed the code to default to the most recent version of SQL if it finds it is working with a version higher, and problem solved - sleep had.
The value of a product like OpenAccess ORM is that it is in competition with other products, open source or otherwise, and it has to: Perform Well, be customer oriented, have a manual (very important), and be easier than doing it yourself or learn an open source system that may or may not be very intuitive.
Throw in that Telerik's support is top notch, and I would say you could do worse - as long as you are willing to give up some control and have to wait for upgrades / patches to handle things like I described above.
First off I want you to know that I am not Telerik evangelist...
We did moved away from Telerik's ASP.NET AJAX controls only because we desired greater control over the look and feel of our UI (we still use the controls for quick internal solutions), but I must say their products are excellent given the right conditions. Our web product team started to use the Open Access ORM for our solutions and honestly we never looked back. The first reason that comes to mind to choose a Telerik solution is grade A support which has never failed to provide a resolution to a problem regarding any of their solutions with in 24hrs usually including sample code... Although I can usually dig through blogs for hours to find solutions for most of my issues regarding Microsoft technology I must say it is nice to have support when we need it.
I would certainly recommend using the Telerik Open access ORM. I have used Telerik products (eg telerik Ajax/Silverlight) for a number of years and they are best in class and the technical support is second to none. The company makes money by providing software that works.
Unfortunately this does not apply to open source since by definition anything can changed without proper control. All it needs is one duff developer and an entire suite can be rendered useless.
In order to use the products correctly, swiftly, and efficiently, it is necessary to be a highly competent web developer.
I'm one of those people that won a license at a users group meeting. Thankfully I got to experience how crappy this software is without paying for it.
I never got to test the ORM capabilities because the Visual Studio integration failed. Any click on the Telerik menu in VS threw an exception. And the VS item template that was supposed to be installed was not there, so I couldn't even begin to test the functionality.
Don't be fooled by the pretty designer screenshots, they can't even get the installer to work correctly.