I am trying to build a NSpeex solution for Windows Phone application. The problem is that a codeplex NSpeex page provides a Silverlight version of the library, but it throws a run-time exceptions, since the code contracts are used in the library, that are not yet present in Silverlight for Windows Phone.
I will go ahead and remove all the lines of code that make use of Contract class. For this I will just do a text search on all the classes in the Visual Studio Project. Is there a better solution. For example, to somehow prohibit the use of some namespaces, so that the VS compiler would show me all the dependency points?
I haven't looked at the source code for this project, but what we usually do in this situation is to either build stub classes that stand in for the missing classes (especially if they are attributes) or remove code through conditional compilation.
The decision on which approach to use depends on the complexity of the problematic code.
Related
I have a .Net project in which some classes (e.g. constants, enums, etc.) are generated by a tool developed in the company. Developers would not participate in changing them. In addition the team using this tool may make mistakes due to the large size of the project.
Is there any way I can enforce some rules like folder structure, naming, proper namespaces, and such things upon inserting those files in the solution? Or is there a way to test these factors?
To enforce a folder structure, you could add custom logic in MSBuild. The logic in MSBuild would run as part of a build. If you know that certain folders must exist as part of a project and/or that certain files must be in certain folders, you can add verification steps in MSBuild and either issue a warning or stop the build with an error.
To enforce name and namespace rules/conventions you can use a static code analyzer. You can use the Microsoft Code Analyzer and/or a third party analyzer. If the 'rules' you need are not available out of box, you can write custom rules.
Both the MSBuild and code analyzer can be used with and without the Visual Studio IDE and can be used locally and in automated builds.
What I seek is achievable with ArchUnitNet. It can be reached here
It helps with testing the folder structure of the project as well as namespace testing and relative naming and even correct inheritance if I'm not mistaken.
I'm writing a C# application that accepts plugins. The way I accomplished this is as follows:
In my solution, create a project that contains a single interface that defines the expected methods of a plugin class.
In the main application, add a reference to this project containing one interface.
Add a third project to the solution which represents a plugin. This plugin also has a reference to the interface project.
In my main application, I scan a plugins folder for files matching a given filename (plugin_.dll). If such files are found, I load the assembly and then use reflection to look for any class that implements the interface. For any such class, I add an instance of it to a List<IPlugin>. The app then has access to all the plugins via this list.
This works great and I have successfully written a couple of very simple plugins.
Here's where I'm struggling:
When I want to test the plugin, I have to first build the solution and then manually copy the built plugin into the correct location which the app scans. I know I can probably automate this by adding a post-build command though.
More importantly, is there a good way to actually debug the code in the plugin? (single-step, exception breaks, etc.) Right now I simply run the app and see what happens. I use extensive Console.WriteLines if I need to trace something. It's far less productive though than using VS's debugger.
Less important at this particular point but could be a thing down the road: how would someone else debug the plugin? More specifically: if I start a new VS solution and make a reference to the interface assembly, is there any reasonable way to debug the code in my new plugin?
I've a very complex solution in c# containing about 20 projects, each of them control a device since it is a driver.
In many cases those projects use similar structures/code (for example everyone as a connect method, a retrive data method and so on).
Is there a tool to analyze the code and create a general "Skeleton" that can be reused?
You can easily create a project template from an existing project from the File>Export Template menu. The process is described in How To: Create Project Templates.
There is no tool that can decide what to include in a skeleton project, as this depends on knowledge of what each project actually does, which parts that can be generalized and which have to be project specific.
You can use duplicate analysis in Visual Studio or Resharper to find repeated code, but this won't tell you what should be in a template and what shouldn't.
What you can do, is:
Extract common functionality in a separate project that all device projects will reference
Create a template from one of the device projects.
Use template parameters to customize the resulting template.
Step #1 will result in a much simpler template, that is easier to customize
When I need to add a reference towards a library, I've always been told to use the "add existing project" method, and referencing the project itself inside my solution.
But here in my new company, the use another method. They have a server which holds the compiled dll's, and keep versions of them so they can reference older versions when a change is too important to refactor older apps.
While I find this system really complicated (I guess there is a lot of work if a program pointing an older version of the dll is updated and needs some changes in this dll), they seem to find it pretty convenient.
What are the best practices for this? Linking the dll directly? Linking the project? And why? Any information is welcome!
Thanks in advance !
I usually take a copy of the compiled dll (if the source project is not available or if I don't need the source) and put it in a folder inside my solution, and then reference that. I check it in to source control along with my project.
I am of the opinion that you should be able to check out a project and build it directly from source control without having to go hunting dlls etc.
The Add existing project method is useful when you want to reference a library project which is develop side by side and you want to test/use it's types and methods and this (Add existing project) method will not be used to add the reference of pre-compiled (dll) files.
Read Project Reference (MSDN) article.
You would include it as a Project when you want to simultaneously work on the library. And that would happen mostly for small(ish) libs that will be distributed with your program (bin folder).
When an assembly is (going to be) installed in the GAC, and thus has its own release cycle, it makes more sense to reference the binary only.
Several combination of the above are possible too.
Adding Compiled dlls is mainly when the code is more or less locked (Architecture level code ) which you hardly ever changes
eg
1) communication layer(remoting/wcf)
2) Generic Gui layer (Wizards/dialog boxes)
3) Security layer (azman stuff)
you only need to change when your product is going to another direction say it uses to use .net remoting as communication now it will be using WCF
Using projects as reference when you are frequently changes referenced projects
also Visual studio works out nicely order of building the projects.
Although your company's approach is probably not very common among Microsoft developers, it is used rather successfully in the Java world. In the long run it is probably better controlled than any alternative, but without a fair amount of support scripts/programs (which, for instance, update projects/solutions automatically when needed) it can easily become unmanageable. In the Java world it is directly supported by tools such as Maven.
We're going to be using Orchard as a base for a particular client. We're a C# shop running VS2K10. We'll throw it in our version control system as per the norm for our projects.
That said, we'll be creating custom modules based on the needs of our clients. What approach does everyone here recommend?
Get full source from CodePlex and check that in
Download just the Orchard web code (similar to Web Platform Installer)
Problem with #1 is that the code base is rather large, but it will allow us to debug the site locally when developing.
What are the caveats with #2? Lack of debugging?
I'm curious what everyone's approach would be for this. I'm inclined to go with #1, get the full source, throw it in SVN, and build off of that.
Thoughts?
If you are going to develop modules using Visual Studio, just use the full source code. Disk space is cheap.
Caveats with #2 are that it's immensely less comfortable. Why bother?
I use the full source version, but I only check the modules and themes that I'm working on into source control.
I did originally use just the web code, but found myself running into lots of little problems that were much easier to track down when using the full source.
I found that only source controlling the stuff I was working on made updating to later versions of Orchard much easier.
I'm no software engineer, but here is what I would do :
Get the source code.
Add it in your VS solution and source control.
Do NOT reference the project(s).
Add a post-build event on that project to copy the dll and the symbols (for debug) in the folders of the project that would otherwise refer this one.
If it crashed in a class from that project's assembly, you'll be able to specify the source code files since you got the symbols, and since you won't be modifying that project on a regular basis, your VS won't rebuild it every time. You could even unload the project if you want to save some memory, however trivial it might be.