So it seems like I have a couple of major options when getting WCF service proxy code into a project in Visual Studio:
Use Visual Studio's built-in tooling for Service References
Use a simple svcutil command, something like svcutil http://[my
endpoint] /namespace:[my namespace] /noconfig (since I use some
fairly standard bindings across projects), and drag the resulting
file into my project (or upgrade in place).
To be clear, option 2 feels like the best one, albiet with no built-in tooling for updating. But the Service Reference dialog generates like a zillion files. Is there any obscure benefit to VS Service References that I'm missing?
Same reason why you build a .net project with VS and not calling the compiler by hand from command line. The I of IDE stands for Integrated, it does things for you so you do not need to do those things manually from many separated places and procedures.
There is usually a way to do many of those things by hand or with a text editor and command prompt but lets be productive :-)
If you also own the service, I'd say don't use either one. Instead, break up your contracts, entities, and client proxies into different assemblies that you can use both on the service and the client.
Kinda like described in WCF The Manual Way... The Right Way.
Related
Ever since I started using ReSharper it's never been clear to me how I can step into my own external sources. Sometimes it's working, but most of the times it is not.
As my frustrations are at its peak I would like to figure out how this works once and for all.
I have two C# solution files (one for my Framework and one for my Platform). I am using code from my Framework in my Platform solution through Nugets.
Both solutions are located on my disk (C:\<project>\framework and C:\<project>\platform). The Framework solution contains several projects (e.g. Framework.Core and Framework.Logging).
When I am debugging my Platform solution I cannot navigate into a method (F11) that is called on one of my Framework components.
As said, this has been working fine for me in the past but now it's not working anymore and I cannot find the solution.
Thanks for your help!
ReSharper doesn't control anything about stepping into external source while debugging. The options in your screenshot control navigating into external source from standard ReSharper navigation commands (go to type, find usages, etc).
In order to debug external sources, you'll need to make sure you have access to the .pdb files for your external code. This must either be side-by-side with the assembly, or available in the symbol cache, or downloaded from a symbol server.
I am writing a networking library using Google Protocol Buffers. I have a Visual Studio project that performs a custom build step to run the Protobuf compiler, and another project that builds the output classes.
I would like to put the client library and server library in separate solutions. But both depend on the same Protocol Buffers classes. Is it OK if they both contain the Protobuf-related projects?
Edit to clarify: I know it's possible to do this, but I am curious if it's considered good practice or not.
Well, I don't think it's a bad idea, but you might want to consider compiling your protocol buffers project into a .dll file and have your client and server side projects refence that instead. Just cleaner in my opinion.
When you make changes to the .dll you can right click the reference to it in your server and client projects and click Update Reference. Simple as that!
That is OK.
I ususally have several solutions (when I have 20+ projects) with the same set of projects. E.g. I have main solution with all projects I need. And development solution where I also include unit tests projects or similar needed for development perposes only.
There are some links that point to best practices in organizing projects and solutions:
SSW Rules to Better Large Builds in Visual Studio.NET
Structuring Solutions and Projects
Managing Dependencies
Hope that helps to figure out what is the best practice could be applied to your case.
Project Linker: Synchronization Tool -- I have read this and still don't understand what the point of it actually is.
Oh, and I tagged this with prismv2 because it seems to have some association to it.
I don't often get what Patterns+Practices does but this one seems straight forward. It is explicitly useful for an app that you want to create for both WPF and Silverlight. You have to have separate projects, the assembly references are very different. Which is painful, any change you make to one project you also have to make to the other. The tool makes it automatic.
I installed WiX 3.5 with Visual Studio 2010, as I've read lots of people saying that WiX is a great alternative to that hellhole that is the Visual Studio Setup project, but it sure seems like it requires a lot more effort to make even the simplest installer. Am I missing something?
In a VS setup project, I can add a project output to my ProgramFilesFolder, and VS automatically sweeps up all the dependent dll's from the other projects in the solution, as well as 3rd-party libraries and such. After reading this from the (apparently somewhat out of date) online docs, I thought maybe WiX finally had something similar, but it doesn't actually pull in dependent libraries--it just makes it easier to add that single project's output to a fragment without a lot of extra typing.
So the best I can see to do is manually add to my WiX setup project every single project in my solution that I want in the installer (and set Harvest to true, since that doesn't seem to be the default). I'd probably write a little perl script to do that. Then I have to determine all the non-project dependent dll's somehow (probably easiest to look at the VS setup project for that) and add by hand some wxs code to include them (since apparently the WiX project only handles references to projects, not raw dll's). Then edit in a simple UI, for which there are samples on the web I can work from. And code for shortcuts.
Is there a better way?
This is a very subjective and long answer type question. From a quality and capability perspective, WiX kills VDPROJ. From a learning curve perspective, not so much.
Check out IntallShield 2010LE ( Limited Edition / Free ) or look at Industrial Strength Windows Installer XML ( IsWiX ) (Disclaimer: I am the coordinator ) I use this tool to do the majority of my heavy lifting and then write small amounts of WiX by hand to glue it all together.
Is there a pre build action or some compiler switch that we can add?
I have just too many projects in our solution at the moment. I want to add new modules and compile them into separate assemblies.I am looking for options where I can avoid adding new projects for each assembly.
I am using Visual Studio 2005.
Also, It will be worthwhile to know if 2008 has better features over this space.
edit #1: There are two development teams working on this project and we want to cut the modules broadly into two verticals and keep the assemblies separate so that the ongoing patches ( post release ) do not overlap with the functionality in two verticals and also the testing footprint is minimized.
Currently the solution has about 8 projects and we need to setup the structure for the second team to start development.
I do not want to end up adding 5 or 6
new projects in the solution but
rather create folders in the existing
projects so separate code for the new
team or some easy way.
No, Visual Studio is still "one project per assembly". Do you really need to have that many different assemblies?
You may be able to write your own build rules which create multiple assemblies from a single project, but I suspect it's going to lead to a world of pain where Visual Studio gets very confused.
If you could give us more details about why you want lots of assemblies, we may be able to help you come up with a different solution.
EDIT: Having read your updated question, it sounds like you would possibly be better off just working off two branches in source control, and merging into the trunk (and updating from the trunk) appropriately. Alternatively, if the two teams really are working on independent parts of the code, maybe separate projects really is the best solution.
One of the problems (IMO) with Visual Studio is that the files in the projects are listed explicitly - which means that the project files become big merge bottlenecks. I prefer the Eclipse model where any source file under a source path is implicitly included in the build (unless you explicitly exclude it).
Neither Visual Studio 2005 nor 2008 lets you create multi-file assemblies. However, you can run the C# compiler at the command line with the '/addmodule:ModuleName' switch and it'll do what you want. For general details on command line usage of csc see this article. For description of the /addmodule switch see this one.
That said, however, you're most-likely taking a non-optimal approach here. In normal situations you should not have to want to create multi-file assemblies just because you have too many projects. Give more details of your general problem so that people can offer suggestions regarding that.
I'd heed the advice you've been given thus far--if you find yourself asking such questions, there's probably a deeper design issue that's being overlooked--but if you really must do what you're suggesting be done, you have several options. You can hack the project file to allow you to compile files into separate assemblies: the project file is an msbuild file, so there's a lot you can do with it. Also, you can simply use an msbuild file for building your projects and solutions. Or you can use a different build system entirely--NAnt is one example.
The likely problem with these suggestions is that they won't be feasible for your work environment. It's no good to start hacking away at project files that other people on your team use, or to just decide that this or that solution is going to be built using your custom msbuild file. There are many good reasons to use something like a single custom msbuild file, or NAnt, to build your projects, but it's always the wrong decision if it's not made with input from everyone the decision affects.