Can you explain to me what it means :
An unmanaged Solution can be published as a managed Solution
Thanks in advance,
Publish is a slightly misleading word to use. What you in fact do in dynamics is Export a solution.
With that said, when you export a solution (as a zip file) you have 2 options during the export process. This is what they are and what each mean:
Unmanaged
When you import this into the target all components included in the solution are installed/overwritten. All of the components are editable on the target environment and fully customisable.
Deleting the solution will not remove any of those components, it just removes the solution reference leaving everything still installed. Think of it like an open box. You empty the contents onto the target, but removing the box simply... removes the box.
In theory this sounds like the worse option, but in a standard release process it's actually more favoured amongst the seasoned developers (that I have worked with anyway).
Managed
Is more of a closed box or a package. All the contents are installed and potentially overwritten (you can choose to maintain customisations, but I'm not sold on this feature yet, it's never proven useful to me).
Using managed solutions gives you control over the "customisability" in the target environment. You can choose to completely lock down a component (effectively make it read-only) or you can allow it to be customised.
Deleting the managed solution completely removes all components from the target server (including data in the entities). Hence why I call it a closed box/package. Although, to be honest, I have never successfully managed to delete a larger solution from an environment so not sold on this feature consistently working.
Managed solutions are usually best saved for "products" or "addons".
Also worth noting, you cannot export a solution which was originally imported as a managed solution into that environment.
Related
I am in the unfortunate situation of having lost the unmanaged solution for our production environment in Dynamics 365. What I do have is an export of the managed solution that I am able to inspect.
I had tried to manually modify the managed solution to be unmanaged by updating <Managed>1</Managed> to 0. However when importing this modified solution into the same environment, the import failed with the message
"unmanaged solution expects full formXml" (error code 0x8004023B)
It's worth noting that I was attempting to import the modified unmanaged solution into an environment where the managed equivalent was already installed and in-use. I am not sure if importing this manually unmanaged solution into a fresh environment would be successful.
Questions:
What are my options in recovering an unmanaged and editable solution from this exported managed solution?
If an unmanaged solution is able to be recovered and installed in Sandbox, will there by any issues in updating the managed solution in
Production?
Is it possibly to simply add on a new solution, dependent on the base managed solution, that would allow me to modify the base
solution? I am pretty sure I can add features to the base solution but
would not be able to change or remove any features of the base
solution.
Would importing this modified unmanaged solution into a fresh environment have a better chance of importing without error?
you might want to check out thi article on how to manipulate solutions via SDK. https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/sample-work-solutions
You shuld be able to re-create the unmanage solution though this.
Use Solution Packager
(https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/compress-extract-solution-file-solutionpackager)
to extract your solution as managed.
In extracted folder in file Other\Solution.xml change Managed to 0.
Use Solution Packager to pack your solution as unmanaged
(/packagetype:Unmanaged) Import it into development organization.
Verify that all your customizations are there and valid.
No guarantees but it should work. You might loose some managed changes for forms and sitemaps. Most probably you aren't using them.
Also please do organization backups before importing solutions into your organizations. Just in case something won't go as expected.
I have some questions regarding the registering/updating of 3rd party plugins that were previously loaded via a managed solution by a 3rd party.
The issue we are having is that they(3rd party) sent us a plugin update and a new plugin outside of the Managed Solution and had us register it manually though the registration tool. Then, next time we tried to import a later version of their solution, the Managed solution import failed. We eventually realized that there where duplicate rows in the pluginassembly and pluginassemblytype table that had the same Pluginassemblyid and plugintypeid respectively with different solutionids.
These solutionids were "Active" which I assume came from the manual registration and "IPM Global" which is our 3rd Party Managed Solution. The only way we were successful in getting the solution to import was to change the overwrite time
on the table(s) to 0 and then delete the "Active" pluginassembly and plugintype records.
Is there any other way to accomplish this same thing that is supported?
BTW. We did try to unregister the plugins before trying this, but there were too many dependencies in our workflows.
Wow, this is a thorny problem. Since you mention updating the tables directly, I'll assume that the system is on-prem.
Registering a plugin that exists in a managed solution outside of that managed solution is something I've never done, and while I have directly updated the plugin registration table, it is certainly something to minimize.
As unpleasant as it sounds, to get back to a good state in a supported way you may be looking at having to:
Backup the SQL database
Backup all the data from any managed solution entities.
Undo all dependencies on the managed solution (i.e. edit all the workflows so they no longer depend on the managed solution). To ease the pain of this piece you might want to experiment with exporting the affected workflows via an unmanaged solution. Then you could delete them rather than trying to weed out the dependencies. Then after you have the managed solution back in the system, you could theoretically import the unmanaged workflow solution to restore the workflow. But, admittedly this working depends on workflows finding the plugin assemblies they depend on by name rather than Id, which I'm not sure is the case - so like I said, experiment.
Unregister the "out-of-band" plugin
Uninstall the managed solution
Install a clean copy of the managed solution, INCLUDING the previously problematic plugin.
Restore/reconfigure the workflows
Restore the managed entities data
It's a lot... so much in fact that I would consider opening a Microsoft support ticket to see if they can provide any alternative methods to correct the situation.
In this situation I personally might also consider unsupported methods like using SQL to copy the tables of any managed entities before deleting the managed solution and then using SQL to copy the data back after the managed solution is fixed. Of course I (almost) never recommend using SQL in an unsupported way, so explore that option at your own risk (and with copious backups).
First, try to avoid direct DB updates in system tables whenever possible. You never know when it will hit you (next solution import, next CRM upgrade, moving to cloud, etc).
I assume that yours vendor solution contains entities and attributes and not only assemblies with SDK message processing steps. Thus you can't just simply remove that managed solution cause there will be data loss. Also I assume there are no workflow activities in their assemblies.
Ask them for solution with properly registered assemblies and SDK message processing steps. Then go into your organization with plugin registration tool (https://msdn.microsoft.com/en-us/library/gg309580.aspx) and unregister their assemblies. Then just import their latest solution. It should be able to import their assemblies with whatever is inside them.
It's good idea to restore copy of prod organization and playthrough whole process in safe environment first.
I am wondering what is the Difference between Managed Solution and UnManaged Solution in CRM 5.0 (2011)?
Unmanaged solution: Essentially the same as 4.0. As soon as someone imports an unmanaged solution into an organization, it becomes an integrated part of the organization and can only be removed by manually removing all parts of the solution. The components of it can be freely edited, changed, and removed.
Managed solution: Managed solutions can be locked down by the creators to not allow or allow editing of forms, adding new forms, changing display names, etc. A managed solution can be easily removed by just deleting the solution, and all components (that aren't needed for another solution) will be removed.
Unmanned Solution**:That solution we are edit update Unmanaged solutions are groups of unmanaged customizations. Any unmanaged customized solution component can be associated with any number of unmanaged solutions.
You create a managed solution by exporting an unmanaged solution and selecting to package it as a managed solution.
Manged Solutions:A managed solution is a completed solution that is intended to be distributed and installed.we cant modify and customizations that solutions.
Also,
an UnManaged solution has no restrictions on what can be customized, and when you make changes to the system through an UnManaged solution the changes remain behind.
Managed solution all customizations are lost when it is deleted. So there is the potential for data loss in that event.
I hope this qualifies as programming related since it involves how to structure a project.
Because I've always used the web site model with VS.net I never had solution and project files and putting everything into source control worked great. I knew that everything I had in my web site directory was all I needed for the web site.
Now I'm using asp.net MVC and it only has a project model so now I have these solution and project files. If I work on it alone it's fine but once other people start to add/delete files from the project our solution file gets messed up and people end up having to grab the latest solution file, see what got changed and then add back/remove their files and check in the solution file again. It's become sort of a problem because sometimes people don't realize the solution file was changed, they make other changes and then when they check in everything other people do an update on their files they find that their files are gone from the project (although still physically on disk).
Is this normal? Is there a way to structure a project so that we don't need to check in solution and project files?
Your developers are not using TFS correctly. You should have multiple check-outs turned on, and everyone needs to be careful to merge their changes correctly when checking in. TFS will prompt you to do this, and accepting the defaults is nearly always the right thing to do.
It's not uncommon to have one or two developers who never get it, and you might have to help them now and then. But every programmer who works on a team needs to learn how to use source control tools correctly. If they can't manage that, they shouldn't be writing software.
[edit] It occurs to me that you might run into these problems if you check in the *.sln file directly, rather than choosing to "Add Solution to Source Control".
I don't think it's normal - what are you using for source control? It sounds like developers aren't respecting changes that others a making - checking in without merging first.
I know that early on in a project, when lots of files are being added & deleted, it can be a problem to keep up - you need to check out the project file, add your files, then check in the new file & project so other developers can also update it. You'll probably have multiple project files in a solution - perhaps one interim solution would be to have one "holding" project for each developer, then clean them up periodically - though these types of temporary fixes do have a tendency to become permanent.
I don't know of a way to set up a project file that's not in source control, though I suppose you could create a script that would generate them.
Having been through this, the key is respect & good communication between the developers.
This tends to happen with TFS multiple check outs. It can be hard to grasp coming from VSS to TFS as VSS allowed one person to check a file out at one time. Auto-merge should work most of the time for you but a couple of rules should ease the pain:
Check in early and often (if you add remove or rename a file check it in straight away even if it is a blank holder)
Before you check in do a get latest, this will ask you to resolve conflicts locally
Try to get continuous integration set up so that developers always know the state of the buidl and whether it is OK to check in\out.
We had a bit fo pain at the start of our current project but it soon settled down when we followed the rules above.
Personally, I think making changes to project and solution files requires discipline and clear (well understood) rules throughout your development team. These files (.sln, .*proj) are the bottlenecks of your project, and any errors or inconsistencies can cost you in team downtime. Changes need to be well thought out, planned and then executed.
They must be secured by source control (which you're already using, excellent) and your team members should work on the basis of only making the changes they need, and not leaving project or solution files checked out for an extended period.
If you are allowing multiple (shared) checkouts, this could become problematic in terms of overwriting another user's changes. Depending on your source control mechanism, people may be required to manually merge changes. Personally, I'd ask people to negotiate their project/solution changes with each other over merging (this can't always be achieved).
A third option if you are using TFS is the shelve feature. If someone needs to make changes locally, they can shelve the changes and merge later.
Lastly, another strategy is to try to architect your solution to be as modularized as possible - so people are distributed, working on separate projects and do not (ideally) have to overlap on too many common areas.
I'm not sure if you are using TFS, as people have mentioned, but if you are (or if you are using source control with similar capabilities) you can set it such that sln and csproj files are exclusive lockouts and are not able to be merged.
We have done this with quite large teams and while it causes some initial issues as people get used to it in the long run it has resolved many issues that were previously causing problems. Essentially you trade longer term merge issues/complexity for short term compile/checkin issues which we have found to be a good trade off.
Once you have set it to forced exclusive checkout and no merge you then get your dev teams used to the fact they should keep locks on the sln and proj files for as shorter time as possible.
Always check them in.
Always check out latest (merge if possible), make sure your change is there, before checking in a new version.
If your source control doesn't require a special action to check in from an old version, GET A DIFFERENT SOURCE CONTROL.
I just wonder what the best approach is to have multiple users work on a Project in Visual Studio 2005 Professional.
We got a Solution with multiple Class Libraries, but when everyone opens the solution, we keep getting the "X was modified, Reload/Discard?" prompt all the time. Just opening one project is an obvious alternative, but I find it harder to use as you can't just see some of the other classes in other projects that way.
Are there any Guidelines for Team Development with VS2005 Pro?
Edit: Thanks. The current environment is a bit limited in the sense there is only 1 PC with RDP Connection, but that will change in the future. Marking the first answer as Accepted, but they are all good :)
What you need is source control.
You should definitely not open the same files over the network on multiple machines. For one thing, Visual Studio has safeguards in place to prevent you from modifying certain files during a build, but it has none of that that will prevent others from modifying the same files over the network.
By setting up source control, each developer will have a separate copy of the files locally on his or her developer machine, and periodically communicate with the source control system to check in/commit changes. After that, other developers can ask for the latest updates when they're ready to retrieve them.
Use source control to keep a central repository of all your code. Then each user checks out their own copy of the source code and works locally. Then submits only the code that changed.
https://en.wikipedia.org/wiki/Version_control
A number of people have recommended using source control and I totally agree. However you also need do the following.
Exclude your personal options files from the repository (eg your .suo files)
Exclude your App.config files from the repository. - Not entirely but you need to have a Template.App.config. You commit that instead, and only copy your App.config into the Template.App.config when you make structural changes. That was each user has their own individual config for testing.
There are probably some other files worth excluding (obj directories and so forth) but thats all I can think of right now.
Peter
This might sound snide, but if you're opening up the solution from a shared location then you're doing something wrong. If that's the case then you should start using source control (something like Subversion) and have everyone check out a copy of the project to work on.
However if you're already using source control, then it might be a symptom of having the wrong things checked in. I find that you only need the sln, and the vcproj under source control.
Otherwise I don't know...
You should definitely, definitely be working with source control!
This will help stop the collisions that are occurring. Also, if you are making changes to the shared projects this often that it is a problem, then also ensure that all code is tested before getting checked in (otherwise they may bust someone else's build), but make sure they check in often (or time gained from not dealing with prompts will be lost in merging conflicts) :)