A little background: I'm writing a set of C# classes to wrap a SOAP connector to another system called Jira. The SOAP connector which Jira exposes has too many functions for my purposes, so I'm attempting to simplify the interface.
My setup: In C#/Visual Studio 2010, my solution is laid out as follows:
JiraService
Properties/
AssemblyInfo.cs
Settings.settings/
References/
...
System.Web.Services
Web References
devjira.soap /* my connector to the jira soap reference i'm wrapping */
Types/ /* these are data classes i'm trying to expose for the user */
Comment.cs
Issue.cs
Project.cs
User.cs
app.config
Jira.cs /* main class I'm trying to provide to user */
Jira.cs is in the JiraService namespace. Comment.cs, Issue.cs, Project.cs, and User.cs are all in the JiraService.Types namespace. Jira.cs essentially exposes a few methods which either take or return the classes found in the Types directory. Under the properties I have the Default namespace set to JiraService and the Output type set to Class Library.
My Problem: When I build the solution I get out JiraService.dll. When I add this reference to another project, the Jira, Comment, Issue, Project, and User classes are not in the JiraService or JiraService.Types namespaces of the included .dll. The only available namespace is JiraService.devjira.soap, which is the library I'm trying to simplify and hide! What am I doing wrong? Why are my classes not showing up in the final library?
Thanks for all your help!
Need to see code to tell for sure, but a few things to check;
1. Did you name your namespaces correctly in all the classes? Folder structure doesn't matter, its the namespace attribute that counts.
2. Are your classes public?
Beyond that, post some sample code please..
Related
I have 2 projects in this app. One of this is supposed to make the connection with the database.
I am trying to add the methods from the BLL project to the MVC_BO. I already added the reference, but when I try the "using BLL" the MVC_BO does not recognize the reference.
Both files in BLL project are using namespace BLL (as you can see in the image below)
enter image description here
Your classes are not public, so nothing is being exported from that namespace. Make your classes public. They are internal by default.
I downloaded the OpenSSL .NET wrapper on Visual C# 2010 express edition and I tried to modify the source code by adding methods and classes in the Crypto library. Then I compiled it and generate new ManagedOpenSSL.DLL.
I made a test program and i put this DLL as a reference to check if my modifications were done.
The result is that I found my new methods (I added them to an existing classes) exist, but my new classes does not exist.
Does some one know why ? thanks for any help.
Did you forget to put public in front of your classes?
public class MyNewClass
{
}
Without seeing any of the code you added, I can only guess that either you added internal classes and thus they cannot be seen, you are not looking in the correct namespace for your classes, or in fact you added no classes at all. Again, without your code, these are only guesses.
Scenario:
I have 2 Projects, MainApplication (which compiles to an exe) and ClassLibrary1.
Now MainApplication references or loads ClassLibrary1, but ClassLibrary1 has no idea about MainApplication.
But I want to use Settings (Dot.Net 2.0's Properties.Settings NOT appSettings) that are defined in MainApplication.
How do you achieve this?
I have seem PLENTY examples that use
System.Configuration.ConfigurationSettings.AppSettings.Get("SettingName");
This is NOT relevant to my situation as appSettings is old school and I am using the newer Properties.Settings mechanisms.
Your help is appreciated :)
I have done some investigating in code.
I can get the setting like this but it is really dirty:
((ClientSettingsSection)ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None).SectionGroups["applicationSettings"].Sections["MainApplication.Properties.Settings"]).Settings.Get("Tester").Value.ValueXml.InnerText;
Maybe someone can provide a more elegant solition
Since the Settings class is defined on the Main project, you cannot directly access it from the class project because you would create a circular dependency.
What you would do is provide the Class library with a delegate it can call to dynamically retrieve the settings from the main project. Create a class that stores a delegate in the Class library and set this delegate to a method defined in the Main project. This methods would encapsulate the instructions needed to retrieve a setting.
And in my opinion, appSettings is not old school, it is just a way of representing configuration parameters that are not specific or customizable by a user.
I have a Silverlight Class Library that I want to use in both my Silverlight and my WebService project.
I am able to create and reference the Library in both projects without any problems, but when I try to use any of the classes in the Library on the Silerlight project, I get an ambiguous reference error between my Library and the Asmx Webservice (apparently, the silverlight project believes that the classes in the class library exist in the webservice).
How can I correct this issue? I have tried rebuilding and cleaning, but it does not seem to work. Can anyone help?
Sounds like the objects you are passing to Silverlight, via the WCF service, are the same objects in your class library. In that case the generated web-reference objects will be given the same names. Linking with the library will then give you 2 sets of objects with the same names.
If you install RIA services, once feature is the ability to share code between client and server by simply adding ".shared" in the class filenames before the extensions. ASMX services are so last century :)
if you don't want to learn the RIA services way of sharing objects across the great-web-divide (which I would recommend), you need to separate the data objects from the functionality you actually want to share client and server side.
To give more specific advice on your current set-up I would need to see more about how it is structured.
A technique you can use is aliasing your using statements:
using MyNameSpace = My.Name.Space;
using MyWebService = My.Web.Service;
Then access all of your objects with these aliases to remove the ambiguities.
Scenario:
Web Site project under .NET 3.5
Visual Studio 2010
WCF Service reference
Problem:
I'm trying to extend a class marked with the DataContract attribute. I though the generated class was declared partial, so that i could easily extend it. I tried declaring a partial class within the same namespace with the same name, but it doesn't seem to recognize what class it's extending. I tried locating the generated code file (Reference.cs) which i thought existed after reading this article inside the reference folder, but it wasn't there. When trying to navigate to the class's definition, i found out it was in a compiled library, and the biggest problem is that it wasn't declared as partial.
Question:
Is this difference related to the fact that i'm using a Web Site and not a Web Project?
If so, is there a way that i could make the code generator (which also seems to compile the generated code) to declare class as partial?
Yes there is a way you can declare your DataContract classes as Partial.
For this you'd want to use the DTO pattern. Basically this means defining "shared" Classes in a different assembly, and having both the Service, and the App which consumes the Service, both reference the assembly with your common classes.
So for example your "DTOs" assembly might contain a DTO called "Product". Ok, so you make them Partial, and next you decorate Product, and which ever other Class with the WCF attributes, like DataContract, and DataMember etc.
Now, you reference you DTO assembly with you Service project, and your Web Project.
Now, when you go to your web project and click on "Add Service Reference", click on the "Advanced", and you'll notice you can enable an option to "resuse referenced assemblies". do that and you'll have full control over you DataContracts.
Empty client reference proxy classes can indeed be a most frustrating problem to solve.
I would recommend that you use the WCF Test Client or command line svcutil.exe. against the service - you can often get a much more detailed error description with these tools than with Visual Studio service reference wizard.
In my case the issues are invariably related to serialization or namespacing issues of the entity / graph - typically mismatched get and set on DataMember properties, missing KnownType on polymorphic entities, or circular references in the graph.
Partial shouldn't be a problem. Just make sure that any additional properties that you want serialized are marked as DataMember.
If all else fails, would recommend that you run a serialization / deserialization unit test against your entity / entity graph.