http://www.c-sharpcorner.com/Forums/Thread/225889/inconsistent-accessibility.aspx
I wish to know whether it is possible to demonstrate behavioural pattern mentioned of FlavorScoop() method by an example.
Your explanation about using access modifier (14th thread of Inconsistent accessibility)
After this (single module) assembly has been compiled, it could (in theory) be added as a reference to another assembly. If code in the latter assembly wanted to call the FlavorScoop method, it would have problems in doing so because it wouldn't have access to the IceCreamCone class.
The compiler is therefore ensuring that these problems won't arise by flagging it as an error now.
using System;
public class Program
{
public static void Main()
{
IceCreamCone vanilla2 = new IceCreamCone("Vanilla", 2);
IceCreamCone chocolate1 = new IceCreamCone("Chocolate", 1);
FlavorScoop(vanilla2);
FlavorScoop(chocolate1);
Console.ReadKey();
}
public static void FlavorScoop(IceCreamCone icc)
{
Console.WriteLine(icc.GetFlavor() + " flavor" + ", " + icc.GetScoops() + " scoop");
}
}
class IceCreamCone
{
string flavor;
int scoop;
public IceCreamCone(string flavor, int scoop)
{
this.flavor = flavor;
this.scoop = scoop;
}
public string GetFlavor()
{
return flavor;
}
public int GetScoops()
{
return scoop;
}
}
Loading
VulpesPosted Aug 22, 2013, 4:10 AM
class IceCreamCone
to:
public class IceCreamCone
The program should now build and run OK.
When you've done that, create a second console application project, delete all the automatically generated code and paste in its place the code in my first post.
Right click the project name in Solution Explorer, select Add Reference and then, under the Browse tab, browse to where the .exe for the first program is stored and OK it.
Now attempt to build and run the second project. If everything is OK, it should display the same output in the console window as the first program did.
Posted Aug 28, 2013, 5:30 PM
VulpesPosted Aug 28, 2013, 5:15 PM
My guess is that 'Remove from Recent References' removes those references that are ticked but 'Clear Recent References' removes them all, ticked or not.
Posted Aug 28, 2013, 4:58 PM
In the Reference Manager Window there is a pop-up window with two texts in it, one is saying "Clear Recent References" other one is saying "Remove from Recent References" it is very difficult to distinguish differences between these two. Please explain the differences. Problem is in attached file.
VulpesPosted Aug 28, 2013, 4:38 PM
Possibly, the .exe is missing because the name is too long to fit in the box.
Posted Aug 28, 2013, 4:35 AM
VulpesPosted Aug 27, 2013, 6:45 AM
The second program must have access to a copy of the first program to execute - it won't know anything about the classes in the first program otherwise.
Using Windows Explorer or the command line, try navigating to this folder:
C:\Users\user\Documents\Visual Studio 2012\Projects\Another assembly\Another assembly\bin
There should be two folders in there: debug and release. The executable, 'Another assembly.exe', should be under the 'release' folder if you've compiled it in release mode.
Otherwise you should find an executable called 'Another asembly.vshost.exe' under the 'debug' folder.
Just check these folders to see if there's a copy of either:
'Going to be added as reference to.exe'
or:
'Going to be added as reference to.vshost.exe'
within them.
Posted Aug 26, 2013, 10:55 AM
I deleted one file which is "Going to be added as reference to.exe" and "Another assembly" file remains intact. But Another assembly program (source code of Another assembly) is still executing.
VulpesPosted Aug 26, 2013, 10:34 AM
Posted Aug 26, 2013, 9:33 AM
VulpesPosted Aug 26, 2013, 8:28 AM
If you right click on the file names and choose Properties, General tab, you can check that the two files are in the same location.
Posted Aug 26, 2013, 6:50 AM
VulpesPosted Aug 25, 2013, 12:00 PM
Going to be added as a reference to (for program.cs)
Another assembly (for program2.cs).
By default the .exes will be given the same names as the solutions, so you should be searching for:
Going to be added as reference to.exe
Another assembly.exe
to see whether they're in the same folder.
Posted Aug 25, 2013, 8:57 AM
In program2.exe search I couldn't find any relevant folder.
VulpesPosted Aug 24, 2013, 7:07 PM
So it's the executables that you should be searching for.
Posted Aug 24, 2013, 5:13 PM
VulpesPosted Aug 24, 2013, 6:56 AM
Just look for program.exe and program2.exe and see if they're in the same folder.
Posted Aug 23, 2013, 8:27 PM
VulpesPosted Aug 23, 2013, 6:41 PM
It's the program.exe file (i.e. after it has been built and added as a reference to program2.exe) where I think you'll find that the Properties Box shows Copy Local to be true.
However, another way to tell is to simply open the folder containing program2.exe and see whether there's a copy of program.exe in there.
Posted Aug 23, 2013, 5:17 PM
Secondly I attach two files. I couldn't see 'Copy Local' in the Properties Box (this question is associated with thread 9).
VulpesPosted Aug 23, 2013, 11:35 AM
Posted Aug 23, 2013, 9:50 AM
VulpesPosted Aug 23, 2013, 6:31 AM
Posted Aug 23, 2013, 6:25 AM
VulpesPosted Aug 22, 2013, 9:18 AM
If you click on program.exe under References in Solution Explorer and then look at the Properties Box, if 'Copy Local' is set to True, then that's what's happened.
Posted Aug 22, 2013, 8:41 AM
Posted Aug 22, 2013, 6:45 AM
VulpesPosted Aug 22, 2013, 5:51 AM
All this should be deleted and replaced with the code in my first post.
Posted Aug 22, 2013, 4:44 AM
Posted Aug 21, 2013, 7:49 PM
VulpesPosted Aug 21, 2013, 5:20 PM
However, if you fix the problem by making the IceCreamCone class public, then you can create another assembly with this code:
using System;
public class Program2
{
public static void Main()
{
IceCreamCone vanilla2 = new IceCreamCone("Vanilla", 2);
IceCreamCone chocolate1 = new IceCreamCone("Chocolate", 1);
Program.FlavorScoop(vanilla2);
Program.FlavorScoop(chocolate1);
Console.ReadKey();
}
}
Add a reference to the first assembly to it so that it will compile.
Finally, when you run it, it should produce the same output as the first assembly did on its own.