I have a solution file (.zip) which contains an unmanaged solution from our supplier.
I also have an access of the instance of the supplier's CRM instance, but that instance doesn't show up the solution in the list as it is unmanaged one, and hence I am unable to export it.
It seems the supplier created the solution on other system, and exported it as unmanaged, and then imported that solution to the system on which he has provide access to me.
I want to import the solution to my target system but as a Managed solution.
Is there any possibility of doing so?
There is no direct way of converting an unmanaged solution to a managed solution.
You can instead import the unmanaged solution to a temporary CRM instance (e.g. an online trial instance or a sandbox instance) and subsequently export it as a managed solution. This managed solution can then be imported in your desired target environment.
As I understand your question, the unmanaged solution has already been imported into a system you have access to, but the solution container itself has been deleted. The unmanaged customizations are still present in the system, no matter if a solution refers to them or not. In that case, you could manually create a new solution containing all the components and subsequently export that as managed.
Related
Iam trying to share a DLL file between three Solutions. The idea is to maintain only one dll. If one of the programs is starting it will use this shared dll.
I know there is a "local copy" switch but the result of "False" is, that the program is looking for the file in its own folder instead of using the Path of the reference.
Or is there another way of sharing the Form without maintaining every single Form on its own?
Thank You
In Solution A there is a project that outputs as a Class Library. In Solution B I need a reference to that library. Currently, I added a reference in Solution B by browsing to a path of Solution A. I am not sure if there is any better solution... my concern is that in the future if Solution A is moved to another folder it will break the Solution B.
I was thinking of copying over dll file directly to Solution B folder but in that case when changes are made on Solution A dll file should be updated manually in Solution B.
One option to make this a bit more sustainable is to have a common directory where you output all your built DLLs and then modify the build process for Solution A to copy built DLLs there (or do this in a separate script). If you expect to expand your usage of this kind of thing, consider using the NuGet package manager. You can set up an internal NuGet server and publish your built DLLs there as a package that Solution B can then consume. That said, this is a lot of work to set up properly, so I wouldn't recommend this unless you are trying to scale this kind of library sharing across many solutions.
The simplest way is to add the project from Solution A to Solution B, using Add -> Existing Project by right-clicking on the solution in the Solution Explorer.
I have created a Silverlight class library which holds a lot of the common utility methods I use day to day in my Silverlight development.
I am starting to play around with Workflow and would like to reuse this common dll. After referencing this dll in my workflow project I see a yellow warning icon beside it.
I can use the functionality from this dll when creating ‘Code Activities’ without issue. After adding the using statement for it all works AOK.
using EquinoxeAISManagementSystem.Common.Helpers;
BUT when I try to import the dll from the activity designer, I do not see the dll in the import window.
If I edit the XAML and add it directly, I get a warning.
Is it possible to reuse Silverlight dlls?
I believe I can answer my own question.
The project EquinoxeAISMAnagementSsystem.Common is part of another solution. I had added this single project for the other solution into my new workflow solution (which I was having this issue in).
When I added the reference to the EquinoxeAISMAnagementSsystem.Common.dll initilly, it was by referencing the project in the workflow solution.
This seems to be the cause of the issue (for workflow anyway).
I was able to correct this issue by adding the EquinoxeAISMAnagementSsystem.Common.dll to a common folder where I keep all my external dlls (for ease of use).
..\Projects\EquinoxeAISManagementSystem.DLL\
I set up the output destination folder for this EquinoxeAISMAnagementSsystem.Common project to the folder above. I was then able to add the reference to Common.dll by browsing directly to the folder above.
Hay presto, all works.
I’m not sure id this is the ‘correct’ way to do things, but I needed to get over this hump.
I would be interested in anyone’s comments and if there is a correct(er), why to fix this issue.
Thanks ….
A change needs to be made in a DLL. The DLL was originally coded in VB6 (not by me), and the source code lost.
It is very simple in its functionality, so I recreated it from scratch, but I only have access to VB Express 2008.
I created it first as a normal DLL then realized it had to be a COM DLL. Fortunately, an excellent article at http://www.codeproject.com/KB/COM/nettocom.aspx tells me how.
But, I don't know anything about GUIDs...
Should I use the same GUID as the original DLL or not? Does it make any difference?
Edit: Does it really matter since it's a COM DLL? It is called into by an Active X control & I can see no reference in the web page to the GUI ... (but I'm just a n00b, so what do I know? ;-)
If you want this library to be a direct replacement of the original and it is fully binary compatible (all interfaces are unchanged) - then yes, you should use the same GUIDs for the class ids and interface ids. If you don't do that users of the original library will not be able to use yours without recompiling their programs.
Beware that binary compatibility is a must for reusing the GUIDs. If you break any interface - change its id and the id of the class implementing it and recompile the client.
The GUIDs acts as a kind of identifier for your COM object and DLL. If you use the same GUID you need to register your new DLL so that the location is updated (i.e. if you don't place it exactly in the same spot and have recreated all interfaces the old DLL previously had registered).
The cleaner approach is to generate a new GUID and modify the caller to use the new GUID/DLL instead.
Simple question... I have a VS 2005 solution that encompasses several reporting services projects. Currently, each project has it's own shared data source making changing the database target very tedious.
Is there a way to share the data source across the entire solution (i.e. all the projects in the solution will use the data source defined in one place?).
I thought I could create a project that just held one data source item and then make all of the other projects dependent upon that one, however, the shared date source in the new project does not appear in the other projects for me to select.
Help! I have looked around the web for info, but not much available. There must be a simple solution to this.
Thanks
I am sorry I somehow overlooked your question when I posted the same.
Nonetheless, a technique I am using is described in an answer to it. It feels a little shady and underhanded but seems to be working so far:
Make a new report project to hold your shared data source. I called mine Data Source.
Copy your shared data source (let's pretend it's called My Shared Data Source) to that new project.
If necessary, copy My Shared Data Source to each actual report project and link things up the way you want. But probably you're already set up like this.
Close Visual Studio to make sure all changes are saved in the filesystem and to make sure it doesn't end up clobbering some of our next, "backstage" edits.
In plain old Windows Explorer (or whatever), delete the My Shared Data Source.rds file from every project folder except Data Source's.
Using a text editor or XML-file editor, edit each project's .rptproj file to change the text of the Project.DataSources.ProjectItem.FullPath element from My Shared Data Source.rds to ..\Data Source\My Shared Data Source.rds.
Now each project still has its own reference to a data source, but all those references happen point to the same underlying physical file, and thus they all share one data source specification.
According to this post by Paul Turley, it appears as if this is not possible. You'll have to copy the data source into each project. The good news is that if you deploy them to the same location, only one data source should exist on the server.
This may not be what you're thinking, but when I'm writing an app consisting of several distinct applicaitons accessing the same data I usually take one of two approaches.
write all of my data access logic into a Class Library project and reference it from the other projects.
Write my data access logic into a Web Service library and add a web reference.
I usually go for option 2 if the data I am accessing is likely to be used in future development, such as accessing company-wide customer lists, etc.