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 ….
Related
I am trying to implement SimplyVBUnitTesting for a VB6 project. The wiki says to add a reference to the main project DLL.
My first thought was, "How would I do that for a standard exe that has an MDI form in it?" (Doesn't seem like you can create a DLL with an MDI form in it.)
My second thought was, "Could I use a project group to add a reference to the main project?"
The documentation that I have seen online seems to always be referring to a main project referencing ActiveX projects (which have no problem forming a DLL). They say that the reference for the other projects should be listed in (Project -> References...) after all of the actively selected references and before the alphabetical listing of unused references. It doesn't seem to be listed there. Can you only make a reference to projects that could make a DLL?
I am surprised as this is exceptionally easy for .NET for every type of project within the same solution. Am I missing something?
(I don't really want to change the original project type to accommodate testing as it might complicate the deployment.)
Unfortunately it's not possible to add a reference to a Standard EXE.
If the classes you wish to test are in a Standard EXE, then the best you can do is to add a SimplyVBUnit Standard EXE project to the project group that contains your main EXE. You can then share the class files from your main EXE with the SimplyVBUnit EXE by adding an existing class and browsing to your main EXE classes. You would add new classes to the SimplyVBUnit project that hold your tests as you normally would. You would have to select the start-up project depending of if you want to run tests or the main application.
It's a cumbersome solution for sure. Especially if your classes have dependencies that access areas in your main EXE. You would need to wrap those dependencies up and set up fake environments in the testing exe.
The way I am going to do is create a SolutionItems directory inside my solution and physically copy all referenced third-party dll files into that folder, then I change reference to that local copy inside the SolutionItems directory. But the question is: does it worth the trouble of manage it manually?
I would think it is a good idea as it is dependency for my application. Without including the dll file, the whole solution wouldn't be able to run inside Visual Studio if the machine don't have the required DevExpress version installed. My Deployment Project will handle dependency correctly regardless, as far as the reference been setup properly.
On the other hand, because DevExpress will normally automatically add references, and I can using Project converter to update version of DevExpress. So without reference to the Local Copy inside solution, it is pretty much working out of the box whenever I am changing reference, or change between DevExpress versions. If instead, I am managing my local copy, I am create more work for myself to maintain the reference and physical copy of dll files. Should I keep it simple as it is now, base on the assumptions that whoever working with this application will need have a copy of DevExpress installed?
We had a similar problem where I work. 5 devs, 1 svn and mulitple copies of DevExpress dlls floating around. We tried at first maintaining a local copy (updated manually) as you describe, this did not work well for us. So yes, the easiest thing to do (in my experience) is require everyone who works on the project have a copy of DevExpress installed.
Looking to make a Solution/Multiproject Template.
While I'm aware a solution template does not exist, I've been researching/trying with some of success. (Link from here (http://stackoverflow.com/questions/2717110/how-to-create-a-solution-template-in-vs2010) have been a big help.
The only issue I'm facing is that, when creating a project from my template, the solution contains brand-new copies of all of the projects involved. What I require is that only ONE project is made as a fresh copy, and that the other projects in the template should reference already-existing projects.
I've made single project templates that hold the DLL references to other projects (which is fine, but it's not what I need.) I need a multi-project template where all but one project involved reference already existing projects...
How would I go about this?
edit:
I'm also finding that any dbml designer.cs that's added to a project are not included in the newly generated solution/projects. They are copied across, but I then have to manually include them in the project. Why is this, and how do I get araound it?
How about using the Feature Builder Power Tool? http://visualstudiogallery.msdn.microsoft.com/67b720f4-9a50-41cb-86a2-82e33b7c5fc4/
It should give you all the freedom to create whatever logic you want during solution setup...
So I couldn't find a workaround for this issue.
What I have managed to do though is make a decent enough template that should be run once, with all references (being relative) pointing to an outside lib folder.
This means I can use the template on a new machine, copy some dlls to a new lib folder, and then work away from there. Not an ideal solution, but it works...
Currently I have 4 solutions that are independent projects, however there is quite a bit of duplicated code when it comes to a few areas of the applications.
At the moment it is simply a few forms and their associated code.
When I want to change or improve something, I have to copy and paste to all relevant projects.
I looked at creating a new project within one of the solutions for the .dll/class library, but I felt that this was incorrect. (Please say if I am wrong).
As it is a component for all the applications, I decided to create a new solution for the .dll/class library and am looking at moving the shared code over to that - but, having never gone down this route before, what are my options from here?
Am I able to then include this solution within the others if I need to make a simple change and have it updated in all the projects or instead, should I always be working on the shared component in a separate instance of Visual Studio, outside of the applications using it?
That's exactly the right way to handle this situation.
You can include projects in multiple solutions by right-clicking the solution and selecting Add Existing Project...
Any changes you then make will appear in all solutions. The only problem this leads to is that it's possible to break one solution from another. This is where automated builds on commit to source control come into their own.
Put shared codes in separate Solution/Project as Class Library,
In post build event of shared projects copy dll's to a specific directory,
Add shared dll's from this directory to other projects/solutions
By doing this each time you build your consumer projects, they will use latest dll's automatically.
Moving the common code into a separate shared assembly is an excellent option.
One thing to think about is to keep your common business logic or business object type code separate from UI related code like custom controls - if you need to then have two common assemblies. This is more work initially, but makes things way easier further down the track when you need to make UI changes or change the control suite you are using.
Maybe that's silly, but I'm confused again when trying to find appropriate names for my projects.
I have a solution with two projects. First project is a library, which will be used by other libraries in the future, for creating plugins for my app. Second project is a exe, which uses first project to create GUI and do some stuff, eg. load plugins.
In similar situation, when one project is a dll and second is an exe, how do you choose names for each project?
Lets say, that I would like to peek a name GraphDemonstration. The exe should be GraphDemonstrationGUI and dll - GraphDemonstration? But exe is not just a GUI. So maybe GraphDemonstration for exe and GraphDemonstrationLib for dll?
I have had similar situation in the past. Maybe there is some kind of naming convention? I don't even know if my "problem" is related to VS only.
GraphDemonstration for your EXE is fine because it describes the purpose of the EXE. However, you said the library will be used by other projects later so the "GraphDemonstration" part of GraphDemonstrationLibrary may not be the best choice. Perhaps GraphLibrary, or GraphHelper, or maybe more specific depending on what is actually included in the library. For example, if the library handles instantiating an Excel object to generate a graph you could call it ExcelGraphHelper.dll.
If this is library of main class CSomeClass I name project SomeClassLibrary.
For projects smillary but non from main object.