I have a referenced assembly that has a (devart) Linq Datacontext in it. We use this same assembly in a bunch of other projects and I don't want to add the source code to my current solution.
How can I add some of the classes in it to a ClassDiagram in my current project?
EDIT in Response to Comments/Answers
I don't have access to the original source code of the external project.
What I mean't was when I said "I don't want to add the source code to my current solution." was I don't want to build up a bunch of partials in my current solution either.
Include a reference to the library in your project.
Go to the object browser (View->Object Browser) and search for your class.
Drag and drop it from the object browser onto the design surface.
I tried it with System.Random and it pulls all the properties and methods.
Related
I've exported an orchestration template using Visual Studio 2012, based on one I previously constructed. It generates a .zip with the following .vstemplate file:
<VSTemplate Type="Item" Version="2.0.0"
xmlns="http://schemas.microsoft.com/developer/vstemplate/2005">
<TemplateData>
<Name>TESTOrchestration</Name>
<Description>Custon Orchestration</Description>
<Icon>Icon.ico</Icon>
<ProjectType>Biztalk</ProjectType>
<DefaultName>TESTOrchestration.odx</DefaultName>
</TemplateData>
<TemplateContent>
<ProjectItem TargetFileName="$fileinputname$.odx" ReplaceParameters="true">Orchestration.odx</ProjectItem>
</TemplateContent>
Using this item template in VS2012 creates an orchestration with the properties shown in the fig. below.
Notice the namespace is that of the original project from which the template was exported.
I want to set the default namespace of this item to include the project name (or even better the path leading to this item within the project). After searching I've yet to find a working example of how to accomplish this in a BizTalk item, namely an .odx.
Thank you for taking the time to read my question. I really hope you will be able to help me with this.
After searching and tinkering around I found out how to accomplish this.
When you export a template from Visual Studio two files are created, a .vstemplate and a template of the exported item, in this case a .odx. In order to alter the namespace, and other attributes, you need to edit this second file and add the information you want.
It is also possible to pass dynamic values by using template parameters in the form of $parameter$, which are documented in Microsoft's library.
So, for example, if you wanted to modify the namespace to include the project name, you would have to edit the exported .odx file and add the parameter $safeprojectname$ or $rootnamespace$ to dynamically set the namespace uppon creation of a new item based on the template.
Probably a pretty fundamental question. When developing a single-project-solution in MSVC++ everything makes a lot of sense, every file is visible to the compiler. When moving to a multiple project solution, none of the interface elements governing project dependence seem to make sense (coming from a .net background.)
For starters it appears setting up project dependencies with that terminology seems to only imply what order the projects are compiled in. There is no more function attached to the definition and addressing objects or methods of one project from another will not work. #including the headers of the dependency doesn't seem to work either, so the dependent project cannot see the files of its dependency. Copying a link of a header from one project to another doesn't work either, where for two projects under the 'Header Files' section, the same file is referenced in both locations. Even with this header references do not work and the files are unconnected. The only way of creating a functional dependency is to add the dependency's paths to the linker/compiler search path of the dependent or worse, simply copying the files of one project to another.
Either I'm missing something or the .NET Visual Studio IDEs have succeeded at what the VC++ IDE has badly failed at.
Edit:
For the sake of asking a specific question, take the following steps for creating a solution in VC++ and I ask if the missing step(s) can be filled in:
Create empty DLL project inside new solution.
Create method in DLL project and compile.
Create new empty executable project.
Create main method in new project.
...
Have main method call function in DLL project.
Preferably fill in the missing step(s) with the most most modern/industry standard/best practice method that best maintains project modularity as intended.
From this I would expect to independently be able to extrapolate and create classes, enumerations etc. in the DLL class and access them all in the executable project, so long as I can find out how this is intended to be done.
In step 2, as per the usual C++ rules, declare the method in the header. Read up on __declspec(DllExport) since the default is that methods are internal to the DLL.
In step 5, as per the usual C++ rules, include the header. Visual C++ needs to know where the header is coming from, so you need to reference the source project. Details vary between Visual Studio versions.
In step 6, you call the method in the normal way. Since it's now declared as __declspec(DllImport), the compiler will leave it to the linker, and the linker will get it from the correct DLL.
I have multiple native C++ projects, one of them is a dll project, and I want to test it.
The problem is that the generated .lib file only contains the definitions for the public interface of the dll, but I would like to test the projects internals.
Since referencing the project does not work (it only works for static libraries) is there a way to add the the generated objs directly in my testing project ?
Also I know that I could include all the source code files in the referenced project. But is there a way to do this considering that the referenced project might change. I would like a method that does not force me to mange each file manually.
I have done some research and I found some answers like in this question:
Reusing object files in Visual Studio 2005
but since I have many small classes exposing all the classes is a bit to tedious.
I found that I can set a Pre Link Event in the Build Event menu.
This allows me to use the following command:
lib -out:"../Debug/tempAllDllObjects.lib" "../MyDLLProject/Debug/*.obj"
now, even if my project is a DLL project I have an additional .lib file that contains all the objects in my project. All I have to do is reference the newly created lib file. This way I can link with all the objects in my DLL project even if they are not in the public interface.
As a note the command can also be set on the DLL project as a Postbuild Event this will increase the efficiency since now the lib file is only generated when changes occur.
How can I share source code between 2 projects in MS Visual Studio 2008 (I'm programming in C++)?
In my case, I have the code for the main game project and now I want to make a simple model editor that uses the game's code, so that whenever I change/add some code in one project it will be updated in the second one.
A common method for doing this, (you'll see it everywhere in open-source packages), is to bundle all the headers into an 'include' folder and all the source into a 'source' folder.
Now in whatever project needs the code, you go to, 'Project Properties->c/c++->General->Additional Include Directories'. Then add the path to the 'include' directory. Finally, add the source/headers to your project, now both projects reference the exact same files, which are in a nice tidy shared location.
You can also build the shared code as a static library or better yet (IMO) a DLL. This involves creating a new project, and learning a little bit about the linker in VS 2008, but really nothing too complicated. This also has the advantage (in the case of a DLL) that the two projects don't re-compile the same code, but rather it is compiled once and used twice.
You can move the required classes into a separate library project and then references this from the second project. Any changes will be automatically picked up.
(I'm not a C++ developer, however the above works for C# projects, I would assume it works for C++ projects too)
You basically have two options:
Create a static library. In this, all the code in the library will be exported and visible to who ever links to this library.
Create a DLL: here, you can define what classes and methods you would like to export and use those.
Lets say you have a class called classA which is defined in classA.h and implemented in classA.cpp and you want to use this same class from two different applications (application B and application C).
Using method 1, you would create a static library by going to file->new win32 project and in the box that pops up, choose application settings and make it a "Static Library". Then in this static library you add both your classA.h and classA.cpp.
To use this static library in application B or C, goto the references and add a reference to the static library project that you just created. then include classA.h in your application (don't forget to set the additional include directories path) and you are good to go.
The approach is very similar for a DLL as well, the difference here would be that you can choose what parts of your code in the DLL are exported (ie visible to outside callers).
From an overall point of view:
With the static library approach, your code will be compiled into both the applications.
With the DLL approach, there will be just one copy of the shared code (in the DLL which will be a separate file) and this will be loaded as required.
i am trying to programmatically do some changes in sharepoint as per the link below
in the link below there is a the second cod snippet is a C sharp code. where do i put this code ? or how can i use this code in sharepoint is not mentioned .. can anyone please tell me ?
http://weblogs.asp.net/wesleybakker/archive/2009/03/05/select-multiple-list-items-in-sharepoint-feature.aspx
I haven't tried any of the code out in the post you linked to, but it looks like the C# code just needs to be compiled into an assembly and deployed to the SharePoint server.
The <CustomAction> element in the feature XML below the C# code references this assembly via the ControlAssembly attribute and the compiled class is referenced by the ControlClass attribute.
If you're adapting the code in the post and creating your own project, ensure that your assembly and class names are correctly referenced in the feature XML file (through the ControlAssembly and ControlClass attributes).
Alternatively you can download the author's SharePoint Solution Pack which contains this feature and others.
you should create a new program to call the method