I am trying to develop a solution in CRM 2011 from VS 2010. When it works it's sort of OK (well CRM is a dog but the code works). But every so often it throws its toys out of the pram and refuses to debug. The current problem I have is that it protests that "The common language runtime was unable to set the breakpoint" on some lines in my routines. For example
private static TimeSpan FindWorkTime(DateTime T1, DateTime T2, Boolean[, ,] supporthours)
{
TimeSpan SlotDuration = new TimeSpan(0, 30, 0);
TimeSpan fwt = new TimeSpan(0); // This I can put a break point on
if (T2 > T1) // This tells me the CLR can not set a breakpoint!
{
DateTime T1S = servicecase.FindTimeSlotStart(T1);
DateTime T2S = servicecase.FindTimeSlotStart(T2);
The code is not optimised. Breakpoints where studio (or CLR or whatever it is that's getting upset) decides to actually recognise them work. So why on earth do some lines and not others just refuse to debug!
I've had a search here and most of the answers involve optimisation (not on) or running two copies of studio (not the case).
Solved at last. The answer of course is that CRM is a pile of ...
The code being run is not the code that has been deployed to the crm server. Even though there is only a single version of the DLL on the server and it is the same version that is on the development system it is not the version of the code that is being run at the server. The code run by CRM appears to be either the code from a DLL or a copy from the database which does not necessarily match the one in the DLL. For whatever reason even though the code was redeployed it appears that CRM still wants to take a old copy from the database. To be stable in addition to deploying the code it needs to be reregistered through their plugin registration tool.
(and that took far too long to find because I assumed that CRM would lie to me about what was failing to be honest the best solution would be to rewrite the app with something other than CRM)
Related
My team currently works with an on-premises TFS 2012 server. I am migrating everything to Visual Studio Team Services, formerly Visual Studio Online. I am starting with a test project and was able to easily get all the code migrated, but can't figure out how to do the same for the work items.
Are there any good guides out there?
New options as of March 29th 2018:
TFS to VSTS migration - The official import option which will import 1 project collection into 1 VSTS account. It automatically imports everything stored in the backup. At the point of writing this, the TFS must be upgraded to TFS 2018 and some work item template customizations must be removed (there are a few well documented features unavailable on VSTS).
VSTS Sync Migrator - Marting Hinshelwood, the uncrowned king of TFS and VSTS migrations, has built his own little tool that can migrate work items from one server/account to another. It can even do migrations from one Team Project to another and while doing it switch between process templates.
VSTS Work Item Migrator - Microsoft has also open sourced a project that they used internally to migrate work items. It's less powerful, but it was made by Microsoft.
Previous answer:
At the moment there isn't a really good story. Your options are:
Start over - easiest :).
Start over and manually recreate items of value - It's a pain, but it's some teams have done these things in the past. keep the old TFS server available in read-only mode and each time you use a work item in the old system, you manually create it in the new one, set all the fields and upload the attachments. Depending on the number of items it'll take you a few sprints to migrate the most important stuff over.
Wait a while longer - Microsoft is currently working on a full fidelity import option which will allow you to upload a Project Collection and it will be exposed as a new VSTS Account (it's not going to be possible to import a project collection into an existing account).
Use Excel for import/export - Will work for most work items, you loose attachments and work item links other than parent/child. The trick is to extract from one Project Collection then copy all fields, except the ID to an Excel sheet bound to the target project collection. You will need to fix all Identity fields (works best when users have the exact same display name on premise as in VSTS) and you'll have to import once with state new and then past the current state/reason over the just imported values and sync again. Test Cases, Plans, Suites and Shared Steps will not be imported with their relations in tact. The approach would be very similar to this one.
Use the TFS Integration Tools - Will work for most work item types, though it will loose custom kanban states and tags. Test cases, Shared steps and their relations will not be imported. This option will allow you to import import work items and source code with their relationships in tact.
Use a 3rd party solution - Out of the available options currently OpsHub offers the most complete solution. For test case and source control link migration you're looking at the commercial edition, which comes at a steep price. It still has a long list of known issues and last time I tried it, I ran into numerous issues which required their support to resolve them.
There are specialized TFS consultants who live off these kinds of migrations if your current state of the work items is precious to you, then you could reach out to them.
See also:
https://www.visualstudio.com/en-us/articles/adopting-vsts
I've been bumping into an issue lately where developers on our team (mostly me) have a tendency to open a project and forget to Get Latest Version before coding and we end up making new changes to old code.
It'd be nice if Visual Studio would know that I'm about to make new changes on old code and either warn me or automatically grab the latest version for me.
Is this possible?
EDIT: I forgot to mention I'm using TFS
Good question, and fortunately for you the answer is 'yes' (since you're using TFS as specified in your comment).
Go to Tools > Options > Source Control (on the left) > Environment and ensure 'Get everything when a solution or project is opened' is checked.
I must add, though, settings like this shouldn't really be used as a substitute for good habits and best practices. You and your team should be aware of the importance of 'get latest' to the point whereby you want to get latest and don't want to work without it (if you're at that stage in the project).
Potential 'downsides' to this:
On the odd occasion, you'll hear our team members say "don't get latest yet". Because of a bad check-in they've made. If they break the build - you'll get that broken build. Not an ideal scenario, it should never happen, but the reality is that it does. You lose an element of that control if it does it automatically.
Not to mention the fact that if your team are forgetting to get latest, there's an even bigger chance of them forgetting to check the changeset for potential issues. The 'resolve conflict' dialog doesn't always highlight every issue you need to be aware of.
I suppose a really minor downside could also be the start-up time of the project (one of the reasons Microsoft more recently got rid of this feature as you mentioned). You're not just opening a solution anymore, you're opening it and waiting for a get latest. Which could, then, require further attention (conflict resolution).
I'm possibly rambling now - but what about when you take on juniors that might not be familiar with source control concepts such as get latest? If it's always been taken care of, they might miss a trick. For example, hypothetically, VS opens but fails to connect to the TFS server as it's temporarily down. Could this cause an already forgetful team to explicitly get latest at a later date?
My company are working at Sharepoint site that we are developing using Visual Studio. The actual installation at the customer is performed by scripts deploying the produced wsp-files. During normal development I mostly use deployment from directly from inside Visual Studio. Unfortunately I often run into problems when trying to deploy my solutions. We are using a server-farm set up, but each developer has their own virtual server, datebase instance and so on.
We have one project file that the define the basic content-type used for different department. This content-type typically define stuff like what period that the list item cover. Each department have their own project that uses the content type combined with department specific fields to form the final list.
One of my current problems is that when I make edits to the content type and deploy it the changes does not seem to propagate. Even though I rebuild the solution and deploy both the base project and the department project with success I still see the old version of the content fields when I create a new department list. Sometimes it helps to retract the projects, but often I literally have to restart everything before it works.
My question is if this problem is caused by Visual Studio not really deploying my new defintions or if there is some architectual aspect of Sharepoint 2010 that might prevent the change to propagate. What steps can I take to lessen the likelihood of the problem occuring?
Have you tried deleting the content type with Central Administration before doing a new deployment? I've found out that Sharepoint don't update/create content types when it finds other one with the same name.
our team is starting to dread updating the service references in our solution because it's a 5+ minute investment. Everything is localhost inside Visual Studio's web server.
My question is - how can I debug what this problem is? It works fine once it is over, but the long delay is crazy. If I had a clue where to look, perhaps I could resolve this.
With VS2012, I ran into the same issue: it took me almost 10 minutes just to update one service reference. I just managed to fix this by re-adding the service in the following way:
Delete the service reference.
Right-click "Service References" and select "Add Service Reference".
Click "Discover" (required in my case, might be different for others).
Select the service that you want to add under "Services".
Give the service a name (under "Namespace" at the bottom").
Press "Advanced".
Uncheck "Reuse types in referenced assemblies" and press "OK".
Press "OK" to add the Service Reference.
For me, the reusage of types was the big issue: now that this is unchecked, new updates only take a few seconds. Since I couldn't find this solution anywhere else, I thought I'd just post it here in case others run into a similar issue.
More than likely the .suo files have gotten ridiculous due to constant refreshes. You can check this by examining the source. If this is the case, you can delete the .suo and update the reference. You might want to make a backup, just in case you forgot some other user settings you have.
The other option is the WSDL for the service has just gotten too damned large and you have to bite the bullet.
If you want to reduce the impact, get the service guys to nail down the contract by using a little known secret called planning. ;-) Honestly, poor planning is often the root cause for a lot of the issues that crop up in VS.
I noticed that using svcutil instead of Add Service Reference in Visual Studio leads to shorter generation times, albeit sometimes the code generated is slightly different (more on that later).
At work we have a WCF service composed of about 100 service operations and 100 service contracts and the proxy generation in Visual Studio 2012 starting from the WSDL exposed by the service takes about 7 minutes. I then tried to use svcutil (without any option) and the generation took only about 2 minutes.
I had to add some options to match the same characteristics configured in the service reference (/enableDataBinding, /serializable, /namespace:*,myns, /syncOnly and collectionType:System.ComponentModel.BindingList'1) and with this option the generation time raised to 3 and a half minutes. Overall the proxy generation is not order of magnitude faster but at least the generation time should be cut in half.
In my experience the two generation methods have some differences that I'd like to point out:
Visual Studio generates datasource files (the one generated by Visual Studio when adding an object datasource to a Windows Forms project, see also this SO thread); svcutil has no option for generating them. It shouldn't be a major problem, since the first time you need to databind to a contract the file should be generated by Visual Studio.
As an aside, if the proxy is compiled in a separate assembly, the referring project could not reuse the generated datasource files since they are not included in the assembly and they will be regenerated anyway.
the ConfigurationName property of the Service Contracts can be different, apparently because the two generation methods consider differently the target namespace in generating the attribute value. This is a problem in our case since we do not use the generated app.config. This however can be managed easily by changing the app.config to match the new value or by (automatically) changing the ConfigurationName property in the generated proxy source.
svcutil does not decorate the ExtensionData property with the attribute Browsable(false) -- this can be a problem if (like us) you use the data contracts as source for databinding in Windows Forms, since all grids now will acquire an additional column for ExtensionData. Like the previous hiccup, this can be handled by adding the attribute using a sed-like tool (for example, I used the PowerShell snippet contained in this answer).
I faced this same problem just now, and updating my service reference was taking around 10-15 minutes sometimes it failed to update. I was frustrated and finally I deleted the reference and then added it once again. And now everything is working fine.
So, I will suggest you to delete the reference and add it again and lets see what happens
Had a slow problem updating webreferences. I was crasy about the times. More than 1 hour.
Some co-worker told to to add my workspace path to exclude from Windows Defender and it solve my problem.
I am new to using Microsoft development tools but have been using Visual Studio 2010, .NET 4 and C# for the past few weeks. I ran into a problem yesterday creating a new project the same way I have been doing it successfully from the start: right-click on the project in the Solution Explorer → Add Reference, which used to bring up this dialog:
Old Dialog Box http://img514.imageshack.us/img514/8978/oldaddreferencedialogue.jpg
After a couple of weeks of no new projects I went to create one yesterday and got a new Add Reference dialog. And trying to add the same dll I have been adding for weeks now resulted in the error seen here:
New Dialog http://img692.imageshack.us/img692/2074/newaddreferencedialogue.png
So, after a painful day trying to determine the cause, it looks to me like it has something to do with the new dialog choking on the # I had in my reference path. When I removed the # everything works as expected. Considering Microsoft has two .NET languages with # in the name, I am surprised that this issue keeps biting people (I have heard of this problem over the years, but I have never done much with Microsoft tools until recently, so of course I did not recall it.)
Questions from a Visual Studio newbie:
Is it common knowledge to not use # in paths?
How/why did I get this new Add Reference dialog when my colleagues, using the same VS version, still have the old dialog that handles # in paths just fine?
My opinion is that if you use weird characters in paths, you get what you deserve. :)
I know there are bugs about '#' character in paths in the core VS product, in addition to whatever may be in the Pro Power Tools extension. There is a surprising amount of code that goes to/from URIs and filenames, and '#' characters (and everything thereafter) get dropped when roundtripping via a System.Uri.
In general, I think it's safe to assume that when creating filenames/paths, there will be 10,000 tools of various quality trying to parse the filenames, and a (large) subset of those tools will fail on 'weird' characters. Just avoid weird characters whenever possible. You gotta choose your battles. In an ideal world, tools would be robust to these kinds of issues. In the real world, it's better to name a path "CSharp" rather than "C#" and move on with more important things in life.
The second dialog is the one from the VS2010 productivity power tools pack - I havent used it myself so dont know of any problems with it. Have you recently installed this?