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.
Related
I need to develop a web service, I received the WSDL (with HORRIBLE unintuitive field names), so I decided to import it as a Service Reference in Visual Studio 2015 to get the classes and the methods to call.
This is the WSDL (I'm sorry I'll need to use pastebin for the characters limit in the body of a question):
http://pastebin.com/B4pFH3jY
The generated code can be found here:
http://pastebin.com/Y9ehXQxy
When I try to build I get several errors:
public partial class Z_CA_WS_ARS_AFC_GET_SCH_CC has the same name of an interface, so I get error.
Lot of items argue about not having as parameter the interface (as it is considered the partial class)
I tried to rename the partial class, but I don't know in the remaining code where I should change and call the class or the interface. The names, as I previously said, don't really help.
When I import in Visual Studio I use the following (default) advanced settings, maybe it helps.
Is there any way to import the WSDL with no issues without asking for a new version (it seems correct to me)?
I even tried to use svcutil with no luck, maybe I used the wrong version.
Thanks for help.
The VS 2013 Express forum doesn't seem to exist at Microsoft so I'd like to ask here..
I am using Microsoft VS Express 2013 to create a C# project. I'd like to be able to add a whatever.cs file to the project so that I can put extra functions there instead of in the default Program.cs file. Back in the old days, we could import code files in C by using a #include but C# in the Visual Studio doesn't seem to do this.
I have been able to successfully add a .cs file, create a class within it, and then instantiate the class and call it's methods from within Program.cs but I'd rather not have to instantiate a variable and have to call functions like something.MyFunction() just to execute some code that exists in another file.
Is this even possible? If not, does anybody know why? I always like the #include in C. You could keep things nice and neat.
Files added to a Visual C# project are automatically "included" in every other file within that namespace. You do not need a using statement unless you change the namespace. Because of this, there is no equivalent of the "#include" directive from C/C++.
Now to handle your use case. C# is inherently object-oriented. It is not expected that you create a million functions and call them individually (like you do in C). So, if you want to use multiple files (and you should!) you have a few options:
Create a normal class (as you have already done) and instantiate it to call its methods. This is the preferred method, and you should be able to come up with plenty of classes for your program that make sense.
Create a static class. These don't have to be instantiated (you access them like MyStaticClass.MyFunc(); ). These are often used as "helper" classes. In general, use sparingly as they are hard to unit test/dependency inject.
Mark your class as partial. This allows you to define the same class over multiple .cs files. Again, this should be used sparingly (see Jon Skeet's answer: https://stackoverflow.com/a/2895068/1783619)
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..
I'm writing a class-library (IE BHO) in C# and currently wrangling with the large volume of what I think is junk output coming from REGASM's generated registry keys.
The short version is this: I only want to expose a handful of classes (currently: ONE class) to IE (and the rest of COM). Only one class has the ClassInterfaceAttribute and GUID stuff set, and I can test that the add-on only requires the COM registry keys for this class -- and yet, REGASM generates GUIDs and registry keys for every class in the entire project.
This is annoying and somewhat disturbing as I do not want my class names sitting in users' registry unless they absolutely have to be there.
To be fair, many of those other classes are marked public because I use them in a driver app from another project in the same solution, to work around IE's debugging black hole...
I'm still very green to COM in general (especially relating to .Net) and I was wondering what is the best way to hide all my other classes from regasm? Or, at least, why these classes that -- even though they are marked public -- are showing up when I haven't set any of the COM flags for them?
Thanks!
Use internal access modifier for stuff that doesn't need to have public modifier. For stuff that really needs public access use ComVisible attribute to partially hide it.
For example:
[ComVisible(false)]
public class ClassToHide {
//whatever
};
public class ClassToExpose {
public void MethodToExpose() {}
[ComVisible(false)]
public void MethodToHide() {}
};
All public member functions and member variables of all public classes are COM-visible by default. So first think of making them internal and if you really need them public hide them from COM with ComVisible.
Try using the /regfile switch - this will output a reg file rather than directly writing all your class names to the registry.
When you have the .reg file you can remove any entries you dont want to be added to the target systems registry, and deploy only those values to the target machine. Depending on how you choose to deploy your software, this might be easier and you would not have to change the code for any of your types.
In fact if you dont have access to the sourcecode, this would be the only way to achieve this.
I wrote a COM component with the same problems.
I separated all the non-COM functions into a separate helper DLL. The COM DLL only contains the code that needs to be registered. Everything else is accessed through the helper DLL.
I found that an easy way to make sure that future code wouldn't accidentally be marked as public rather than internal and show up in the registry.
Set ComVisible attribute to false in AssemblyInfo file and set apply ComVisible for only the desired classes.
How can a .net class library project and resulting dll be protected so it cant be referenced by other applications (.net projects) except those projects in my own solution?
I think you can't forbid other applications to reference you library.
You can make library's classes internal and provide access to them via InternalVisibleTo attribute but it won't save you from reflection.
Yep, aku is right. In reality if you want certain types & methods to only be accessible to one application, you're better off compiling it all into one exe & marking those types all internal. You can then obfuscate the code to avoid the issue with reflection (see here)
Forgive my ignorance, but if they're all class libraries, what does the code do? Isn't the purpose of having a dll so that the code can be referenced.
In any case if you mark everything internal it won't be able to be accessed outside its own library
I think what deanbates is saying is that he is trying to find a way to keep a DLL public within his own application and private for everything else