I use a copy of customer's UAT environment as my Dev. I worked in a solution on top of all other solutions (add existing), however, I come to import into Live (staging), my solution import errors. In UAT, there was a 3rd party managed solution that did not make it to customer’s Live, I only just found out. So when importing to Live, it first errors about that missing 3rd party managed solution, then when I try to import that 3rd party managed solution, the import errors on some missing components; some of the reported missing components don't even exist in UAT where that solution is meant to have already been installed, and some of the reported missing components exist in both environments, but I customised them in my solution.
What are my options to resolve?
Hypothetically, would importing that 3rd party solution unmanaged instead of managed untangle it?
Why was it managed in UAT in the first place? Does it matter which environment that 3rd party managed solution was created in the first place?
I'm not sure of your solution structure. CMIIW, this is from my understanding of your question. You'd have:
in UAT
Your custom solution - Unmanaged, 3rd Party Solution - Managed
in Live
No solution at all.
I have a question, do you modify anything (form/fields/view) from 3rd party's solution?
And is your client using that 3rd party solution?
This is my opinion to answer your questions:
What are my options to resolve?
If that 3rd party solution is not used:
Re-create your solution on fresh CRM deployment, so it will not affect/be affected by any 3rd party solution
If that 3rd party solution used:
Install 3rd party's managed solution first, then import your custom solution (preferably export as "managed"
Hypothetically, would importing that 3rd party solution unmanaged instead of managed untangle it?
AFAIK, you can't import that 3rd party solution as unmanaged unless they give you the unmanaged solution. IMHO, from my experience with CRM 2011, I always try not to have more than 1 unmanaged solution in 1 deployment. And the point of using managed solution is like "released" version of your solution. unless you need the system to change the solution overtime, I reckon it's better to keep it in managed solution.
Why was it managed in UAT in the first place? Does it matter which environment that 3rd party managed solution was created in the first place?
The reason it is in UAT in the first place, maybe you can clarify with the client, what are they using that solution for. Maybe they need that solution for their CRM.
AFAIK, it doesn't matter from which environment that 3rd party managed solution was created in the first place. That's their "released" product.
Cheers.
Related
I need to delete a managed solution from an organisation without losing the data or the fields inside... So obviously there are dependency issues. I added the same solution unmanaged with a different name, hoping that this would solve the dependency issues but when I try to delete the managed solution is still get a whole list.
Does anyone have an idea how I can fix this?
You cannot fix this in a supported way (through GUI and/or organization service).
My first idea would be to try and remove the solution components from the managed solution first and finally remove the solution itself. There actually is a RemoveSolutionComponentRequest, but according to the SDK this request is only valid for unmanaged solutions.
If you need to remove particular dependencies, you could try the DisassociateRequest on the Dependency entity. I don't know if it will work in your scenario, but maybe it is worth to give it a try.
A last resort would be to remove the managed solution, along with its components and dependencies directly from the database. Be very cautious with this approach: it is unsupported and potentially you can end up with a system that does not allow you to import solutions at all.
Is it possible to turn off Entity Framework using the web.config? In the application I'm developing we have the following environments
Development
Continuous Integration
Integration Testing
Production
The Integration Testing and Production databases are managed by a database administrator, so we have to send them a script to make changes to the database.
I've spent hours Googling and looking through old projects, and I can't find how to do this or remember if we ever turned off migrations on the old projects in the first place.
From the lack of information I'm doubting if what I'm asking is needed or possible, but there is something in the back of my head that's annoying me about this so I thought I'd ask the experts.
The easiest method is to simply delete the dbo._MigrationHistory table from these environments. If that table doesn't exist, then only an "initial" migration can ever be generated against that database, which will fail if someone tries to actually apply it to a database with existing tables.
You could set the database initializer in the config file as described at the bottom here, so you can have an updating initializer in the environments you want
I want to test third party developer apps with robotium. The problem is both apk should sign with same keys. So if third party developer put constraint or some check on run time for particular signature , how can i test?
Resigning is not a solution in this case? And also the other solution i can think of multi sign. Is there any better way?
PS: I already went through related threads. I apologies if i have missed any.
I had something similar happen, and the fix isn't easy. I wrote a Robotium program for an app that was built by a third party, but they signed it with an encrypted signature. What I had to do was write an Ant script that had a KeySigner inside of it that made the two signatures match. Even with that though, I still have 4 things I have to do in order to launch the test app.
I guess the short answer is: No, unless you have the signature or can create a new one, your a out of luck.
Hope this helps.
I'm working on a bunch of solutions which uses a third party DLL from vendors like Telerik. We use the dll in most of your solutions. But when i uninstall any of the solutions the dll is getting removed from the assembly. This is a very unfortunate behavior.
I guess even putting the dll in the bin folder wont help it. Because i can use multiple solutions in a same web application. In that case if i remove on solution it is removing the dll from bin folder too.
What is the workaround for this ugly issue?
This is indeed painful. You could consider merging 3rd party DLLs in using ilmerge. Additional approaches can be found in Muhimbi's free SharePoint Coding Guidelines (Chapters 8 and 9)
One option is not to include the third party DLLs in your individual solutions. Anything that gets installed with a solution will be removed when you uninstall that solution. You can have a 'framework' solution that installs common DLLs. This way, those common DLLs are only removed if you remove your framework solution. Or you could have a single solution installer for each shared DLL if you want more fine-grained control over them.
See also the question on SharePoint.SE: Multiple solutions using shared dlls can cause havoc when individual solutions are retracted
We have a class library where we keep a lot of the stuff that we often use when doing sharepoint development. How would you go around deploying this? Right now our best bet is to have it in a separate solution, and deploy that so that the assembly is deployed to GAC. That way we ensure that the assembly is deployed to all application tiers and is available.
Is there a better approach than this?
GAC, of course, is the easiest way to deploy an assembly; however, what if you don't want to share this assembly across an entire server. Or what if the license doesn't permit that.
So, there are two ways to deploy an assembly:
GAC (you already know about it)
BIN folder. To deploy your assembly to the bin folder of your site (e.g. C:\Inetpub\wwwroot\wss\VirtualDirectories\80) you'll need to create a custom Security Policy file and change a security level in the web.config. This is not easy at all and can be quite frustrating but may be well worth it.
More information: http://msdn.microsoft.com/en-us/library/cc768621.aspx
The GAC is usually your best choice. Like ensuring you deploy to all applications, it's also easier in terms of security.
If I remember correctly, putting it in the GAC is the recommended course of action.
Also, remember that you have to add to the SafeControls list in the web.config.
http://grounding.co.za/blogs/brett/archive/2008/05/23/sharepoint-register-an-assembly-as-a-safe-control-in-the-web-config-file.aspx
I've decided to deploy it to GAC since the assembly doesn't pose a security risk since it will not be used from Web Parts.
I've researched a bit and deploying to gac is the recommended way to do it. You could argue that everything but Web Parts should be deployed to GAC. Since Web Parts pose a potentially security risk it can be a good idea to make your own CAS and deploy it to sharepoint bin.
Cheers.
Note that if you do decide to deploy to the BIN folder, you can deploy custom security policy settings such as new Permission Sets through your solution manifest file.