My case is the next one: We have a Dynamics CRM online 2016 with some solutions that a third party created and I need to bring the whole code of one solution, I need to see the code of all the plugins, workflows and Javascript files that the solution has.
I tried in Visual Studio creating a new Dynamics CRM project and then select "New Visual Studio Solution for Dynamics CRM". Then I connected to our Dynamics CRM server and I chose the solution that I wanted. The problem is that with these steps only brings me the structure of the solution with its plugins and workflow but it doesn't bring me the code (plugins and workflows code) that is what I actually wanted. I need to modify a plugin that is already done by the third party company.
I will appreciate if someone can help me with my question. I'm new in the community and any advice will be appreciate.
New Dynamics CRM project
Plugins are compiled and stored on the disk/database as dlls. So unless you own the source code, there is no way to achieve what you are trying to do.
What you can try doing though it to use a decompiler like dotpeek to extract the source if it is not obfuscated. You can then copy the source and make necessary changes, deploy the plugin and disable the other plugin.
Have you considered reaching out to the third party vendor? They might be able to handle your issue a lot better than trying to extract the source through a complex method only to find out it still will take several days to understand their approach properly. You would think Occam's Razor would apply here.
Related
I have few question regarding solution:
How to lock the solution in the mscrm dynamics 2011 ?
How would we manage , if multiple developer are working in the similar solution?
What is solution resolution conflict , How do we resolve ?
There is no way to specifically lock the solution within Microsoft Dynamics CRM. We utilise TFS and Visual Studio to ensure that if a developer is working on Entity X, then they follow standard procedure to check in and check out the EntityX.OnLoad.js and EntityX.OnChange.js jscript files
Careful management of development tasks and who is working on what aspect of the solution. Where possible, we try to segregate entities to different developers at the beginning of the development phase. During the UAT/defect resolution phases, we make individual developers responsible for entire entities.
There is no automated way to resolve this, conflicts will have to be managed manually. It is very easy for a developer to overwrite somebody else's changes with a susequent publish of the solution. This is where it helps to use tools like TFS/VS.NET to manage the JScript. It doesn't, however, help with the form configurations.
TFS 2012 includes excellent support for code-reviewing changesets. However, we have some legacy projects that we want to code review. Once the quality has been brought up to spec, we will start using changeset reviews - however the code changes infrequently, so it's not practical to just review the changesets and improve quality through natural code-churn.
Is it possible to code-review a file or project in it's entirety, rather than just a changeset?
In TFS 2012 this is not an option. If the project is small enough there is a trick, you can right-click the folder in source control, do "checkout..." and then request the review. That allows you to review up to 4000 files at a time.
In TFS 2013 a new feature was added, Lightweight Code Commenting in Web Access. This allows you to annotate the code directly from the code tab in Web Access.
There are 3rd party code review options available on Codeplex, I haven't used them in quite a while, but they might add something more to your liking:
Team review
Team Code Review Workflow
Malevich
Has Microsoft addressed the difficulty of creating a SP site after creating the Team Project in TFS 2012? I am aware of the methods outlined here, but I was hoping they had come up with something slicker in the new version. If not, does anybody know of a better method or tool than the one suggested in the previous link?
The TFS Power Tools has a command tfpt addprojectportal that will create the SharePoint site for you after the Team Project has already been created. You will need to know process template that was used to create the team project. You will be able to find all the options you need for the command by using the /? switch.
I have developed a sharepoint 2010 visual webpart application with multiple visual webparts using visual studio 2010. I am able to deploy it successfully to Production server using commands given below:
Add-SPSolution c:\sp\MySampleProject.wsp
Install-SPSolution -Identity MySampleProject.wsp -WebApplication https://MYURL -GACDeployment
In my visual webparts, I am referencing some of the sharepoint custom LISTs and doing add/update operations with list items. Now If I deploy the webpart manually using the commands above, I also need to create all of the reference LISTS at production server. For this what I do, i just take list template to production and replicates the list structure to production.
Is there any way, I could create a auto installer(EXE SETUP or MSI) that should be able to create all the lists as well as deploy all of the webparts to production server. I know this can be done, as whenever we purchase some third party webparts from other vendors, they provide us MSI or other executables that we just execute, and it does everything for US. But I am not sure how to do it. What tool they use to develop these kind of installers.
Any HELP or suggestion ? ?
CodePlex may have the utility you need. Microsoft doesn't provide an out of the box solution that I'm aware of. From the looks of it, this may be what most 3rd party developers use as well
http://sharepointinstaller.codeplex.com/
Your feature should be creating these dependant lists/list items on activation, then add the web part to the gallery. This is exactly what feature activation is for!
In reality, I would have them as two features (both scoped to the site collection level). One feature creates the lists/list items, and the second deploys the web part. The second would be dependant on the first. The first one could be a "hidden" feature if you wish.
Whether or not you remove those lists on deactivation is up to you. There's good arguments either way.
Greetings all,
I have posted this on the MSDN managed news groups as well as a BizTalk site, but I am not sure they get enough traffic that as I don't seem to be getting a response.
Help me StackOverflow, your my only hope.
I am in the process of upgrading our Visual Studio BizTalk projects from BizTalk 2006 R2 to BizTalk 2009.
I start VS 2008 SP1, load up the VS 2005 solution with all our VS 2005 artifacts in it, and the Visual Studio Conversion Wizard starts. All good to here.
The wizard properly reports that the projects which will be updated. These look good. I press Finish and the conversion tool goes and does its conversion thing. The wizard reports that all projects have been converted successfully, However when I view the conversion log, it says that none of the BizTalk projects were converted. If I expand the node on of the non-converted projects, there is no error information as to why it didn't convert.
The two biztalk projects in the solution (the others are c# projects) are both greyed out and VS.Net 2008 says they are unavailable.
If I then right click on the project and select "Reload" the conversion wizard comes up again, this time it asks to create a backup before converting. I select yes to the default location and hit Next. It tells me it's ready to convert, when I hit Finish I get the nice little dialog window:
The operation could not be completed. Unspecified error.
If I look at the conversion log this time, I see the error: Conversion Issues - your.project\your.project.btproj: Error converting project file. Child element <BIZTALK> of element <VisualStudioProject> is not valid.
There are a couple of posts on the net about this issue but no concrete resolutions:
http://dennismulder.net/cs/blogs/dennism/archive/2009/04/25/trouble-migrating-from-biztalk-2006-r2-to-2009.aspx#comments
http://msdn.microsoft.com/en-us/library/dd257156.aspx
The msdn article mentions the project needing a solution file, so I can't see how that applies as the project is already part of an existing VS 2005 solution.
Does anyone have some ideas/thoughts on this? If I have to, I can resort to just creating new BizTalk projects and re-adding the BizTalk artifacts to them, but we have a number of solutions which will need to be converted and if there is a simple fix to get the conversion wizard to work, I would rather go down that route.
Thanks in advance all.
cmb..
** Update - 20090806 **
After some cutting and pasting of .btproj files I have determined the upgrade wizard does not like the fact that I renamed my project build name from Development to Debug
Greetings,
Ok, I openned an incident with Microsoft about this.
Basically the issue in my case came down to the fact that I renamed the build configurations from Development and Deployment to Debug and Release (to match what every other Visual Studio project calls their build configurations). Apparently, the upgrade wizard for BizTalk, doesn't like this very much.
Anyways, Below is the summary email I received from the support engineer at Microsoft about what the problem is and how to fix it. It comes down to hand tinkering with the .sln and .btproj files. Alas..
The default configuration names
(Development and Deployment) for
BizTalk project should not be
modified. Up to BizTalk 2006 R2 it was
not a “true” integration of BizTalk
project systems with the visual studio
in many ways. For that matter, from
supportability point of view, changing
the default configurations is not
recommended. However, you can add your
own configurations without altering
the default configurations. Also it is
not supported modifying the BizTalk
Project template files for Visual
Studio.
In your case, you have re-named the
default configuration names to some
other values. Because of this change
entries for those configuration were
not appearing in the metadata under
various VS files. I tried playing
around with those setting and
eventually with following steps got
the project upgrade working for the
sample project that you provided.
For solution file under GlobalSection(SolutionConfigurationPlatforms)
= preSolution section I did not see entry for default Development
configuration. Added following entry
there Development|.NET =
Development|.NET (here we need default
entries for deployment and
development)
For solution file under GlobalSection(ProjectConfigurationPlatforms)
= postSolution I did not see entry for default Development configuration.
Added following entries there
{3B54116C-9D09-4DAF-9AFD-62EDA64AC12A}.Development|.NET.ActiveCfg
= Development|.NET {3B54116C-9D09-4DAF-9AFD-62EDA64AC12A}.Development|.NET.Build.0
= Development|.NET (here we need default entries for deployment and
development)
For project file under section did not see section
for default Development configuration
Added following entry there (here we need default entries for deployment and
development)
Delete user options file (as it is not needed for the upgrade process –
VS will create the one when you open
the project)
Opened the project on BizTalk 2009 VS 2008 box. Upgrade process is
successful.
The GUIDs are specific to BizTalk
project files. If there are multiple
BizTalk project as a part of the
solution, you have to add the entries
for default configuration for each and
every project in the solution.
can you confirm whether or not you have checked the readonly attributes on all files in the project.
i had the same problem because it was trying to convert a file that was under source control, exactly as laid out in that one link u provided.
after removing the source control bindings i ran the conversion again and it worked
Found this issue when I searched for the current problem I have with BTS09/VS2008 which is I can't add BizTalk projects to a solution, what is going on anybody know about this one
I have been wittering on about the conversion problem since the launch of BTS09/VS2008 nobody seems to have taken me seriously I believe Dennis Mulder was going to raise the issue with Microsoft but haven't heard anything back. As you have found the Microsoft response is just not worth bothering about, if you are converting from BTS06 to 09 then it's a fair chance you will have a sln file, also removing the source control elements didn't work for me either, I actually opened a solution in vs2005 removed all the source control elements and save the solution, then did a conversion to vs2008 didn't work. One very interesting point one of the solutions I tried converting, some of the BizTalk projects did get converted some didn't, spent hours trying to see where the differences once again to no avail. You obviously can create new solutions/projects and add the in the relevant artefacts to these projects BUT WHY should we need to do this, this to me could be a potential showstopper in organisations that have many or large solutions to convert.
Microsoft needs to take this problem seriously and come up with a solution.
My take on this is that it really highlights how many people have moved to BTS09 NOT A LOT if so then I am sure there would have been a resolve to this by now.
Jim,
There are few things. From Dennis Mulder blog post and comments, it looks like Dennis problem is sorted by removing the source control bindings. He is not going to raise a support ticket with MS, he suggested you to open one if required.
In the MSDN page http://msdn.microsoft.com/en-us/library/dd257156(BTS.10).aspx it clearly states the supported migration path is only from BizTalk 2006 R2 to 2009. There is no support from BizTalk 2006 to 2009.
To address your very first line "I can't add BizTalk projects to a solution", Are you able to create new simple BizTalk projects in VS 2008 without any issues?The reason I'm asking this is, there is a chance you might have installed BizTalk and VS in wrong order. It may be worth reinstalling just the developer components of BizTalk Server.
This problem exists in 2010 also when migrating 2006R2 solutions to BizTalk 2010.
I have found a method that works with the least amount of effort possible. It does not require two environments (old and new) but does require the original, unconverted solution-files to work.
http://justbizzie.blogspot.com/2010/10/migrating-biztalk-2006r2-sources-to.html
Let me know if this is also good when migrating to 2009. I expect it to be :)