I see that my application has the wrong name.
When I go to:
Project -> Application properties...
I see an Assembly name and a default namespace.
Is it safe to just change these two to the values which would better represent my app or will it break something?
Its probably fine to change those two settings:
Assembly name is the name of the output assembly (without the extension)
Default namespace is the name of the namespace that Visual Studio uses when adding new code files.
As long as you don't have some code that depends on the assembly having a certain name you should be fine.
Yes, it is safe. Assembly name is your .exe or .dll file name. Default Namespace, in C#, is the default namespace inserte in top of your files when you create a new file. In VB.NET the "default namespace" means something different (it is prepended to every namespace you define in your project)
Yes, the default namespace is always safe to change. This will just affect what namespace Visual Studio will use when you create a new file in your project. It will not affect existing types; you will have to change those manually.
Assembly name is likewise safe to change.
However, if you have built other software against this assembly or distributed the assembly to others then changing the namespaces of types or the assembly name is a breaking change, and will cause those applications or assemblies to fail if used with a new version of your assembly.
You can certainly change them, but changing them will have consequences. Changing the assembly name simply changes the name of the output DLL or EXE file. The contents are basically unchanged, but anything that references your assembly will need to update the reference.
Changing the root namespace is a little more annoying, but it is also allowed. You will likely end up having to go through a lot of files and fix namespace references, and like renaming the assembly, anything that references your assembly will need to be updated.
From an API perspective, both of these are 'breaking' changes due to the required changes to anyone who references your assembly.
If it is a ClickOnce Application, you will have issues in autoupdate for existing installations.
Related
I have a problem understanding the difference between namespaces and assemblies.
So let's say that I make open Visual Studio, and I create a new project. I will name the project "Project A". The Solution Explorer will look like this:
Now, as far as I understood, the "Solution 'Project_A'(1 project)" is the assembly & "Project_A" that is right under it is the first namespace. Now, I know that I can add multiple "nested" namespaces with different classes. So I can make another class called X and then make a new folder in "Project_A", so a new namespace that will be called "MainClasses" and add the classes A & B there so that it would look like this:
So now, if I'm not wrong: I have the assembly "Project_A" that has the namespace "Project_A". The namespace "Project_A" includes a class called X & another namespace with classes A & B.
Now, if I go to "Solution 'Project_A'(1 project)" and I click on Add->New Project, I will make a new namespace with the name "Project_B", and add another class to the new namespace called Y, I will now have:
The assembly "Project_A" that will contain the namespace "Project_A" & "Project_B", and it will look like this:
Can somebody please correct me if I am wrong and tell me the right way. So what is the exact difference between namespaces & assemblies when working with c# in visual studio. Showing some screenshots would be the best, if you can do it, of course. Thank you
An assembly is an exe (executable) or a dll (dynamic link library) and it is a software primary "component" (not in the sense of OOP component or control). Sometimes named package.
What exactly is an Assembly in C# or .NET?
https://learn.microsoft.com/dotnet/standard/assembly/
A namespace is a code organization feature.
https://www.tutorialspoint.com/csharp/csharp_namespaces.htm
https://learn.microsoft.com/dotnet/csharp/programming-guide/namespaces/
An assembly that is like a partition can contains one or more namespaces that are like folders.
When an assembly is added to the references of the project, you can access to all its namespaces with the using directive at the beginning of the file or by specifying full access directly in the code.
Example
The assembly System.dll contains several namespaces like System and System.IO as well as System.Threading and so on.
using System.IO;
var lines = File.ReadAllLines(...);
Or:
var lines = System.IO.File.ReadAllLines(...);
...
These two concepts are not related. It's only by default that your initial namespace takes the name of your project.
By default each of your projects, contain the global namespace and your own. You can rename the default name of your namespace to anything you want without an issue.
The assembly:
Assemblies form the fundamental units of deployment, version control, reuse, activation scoping, and security permissions for .NET-based applications. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. Assemblies take the form of executable (.exe) or dynamic link library (.dll) files, and are the building blocks of .NET applications. They provide the common language runtime with the information it needs to be aware of type implementations.
The namespace:
Namespaces have the following properties:
They organize large code projects.
They are delimited by using the . operator.
The using directive obviates the requirement to specify the name of the namespace for every class.
The global namespace is the "root" namespace: global::System will always refer to the .NET System namespace.
The namespace for the project is set in the project properties. It is by default set to the assembly name and class files inherit this name when created, but you can change to any name you like. If you add a folder and put a file in it, the folder name gets appended to the parent (for the first folder this is the assembly) namespace. Again you can change this to any arbitrary name.
I found source of WPF.MDI and I try to use it in my project without any specific dlls. So, I added source into the project
Then, wrote xmlns declaration xmlns:mdi="clr-namespace:WPF.MDI" and created a container with MdiChild
<mdi:MdiContainer Theme="Aero">
<mdi:MdiChild />
</mdi:MdiContainer>
But, I received an error XamlParseException.
I guess, I do it wrong at all. But, there is any solutions for this?
UPDATE:
When I put WPF.MDI.dll into folder with .exe file and start it - there is no errors. Why it wants to find dll?
Try setting your namespace declaration like this:
xmlns:mdi="clr-namespace:WPF.MDI;assembly=MDISource"
So add the assembly part.
You need to add this if your class is in a different assembly. See MSDN:
assembly= The assembly that contains some or all of the referenced CLR
namespace. This value is typically just the name of the assembly, not
the path, and does not include the extension (such as .dll or .exe).
The path to that assembly must be established as a project reference
in the project file that contains the XAML you are trying to map. In
order to incorporate versioning and strong-name signing, the assembly
value can be a string as defined by AssemblyName, rather than the
simple string name.
assembly can be omitted if the clr-namespace referenced is being defined within the same assembly as the application code that is referencing the custom classes. Or, an equivalent syntax for this case is to specify assembly=, with no string token following the equals sign.
UPDATE
Read this answer.
The problem was solved after deleting the strings 96-100 in MdiContainer.cs
if (Environment.OSVersion.Version.Major == 5)
ThemeValueChanged(this, new DependencyPropertyChangedEventArgs(ThemeProperty, Theme, ThemeType.Luna));
else
ThemeValueChanged(this, new DependencyPropertyChangedEventArgs(ThemeProperty, Theme, ThemeType.Aero));
I am working on an assignment that specified "Do not use any external libraries". So I created a c# application, and the first thing I did was remove all the dll's references by default... including "System.dll".
However, I can still add this to my code:
using System;
using System.IO;
I was just curious as to how come I do not need to have System.dll as a reference in my project to do this. Thanks!
mscorlib.dll includes items in both those namespaces.
You need to right-click your project > Properties > Build > Advanced... and check "Do not reference mscorlib.dll" to remove this reference.
Different assemblies can contribute to the same namespace.
Even if you don't reference System.dll, you are still referencing (implicitly) mscorlib.dll which contributes many types to the System namespace.
These references are probably defined in your Web.config or the Machine.config file so they're included by default.
These are the default libraries.I think your question is that "Dont use third party dlls"
Another thing to consider is, if you're compiling directly through the command line, a default set of switches, including default library references, is parsed by the compiler through the default response file (csc.rsp), located in the same directory as the compiler. The fact that you are able to import namespaces from the Base Class Library without explicitly referencing them at compile time is due to the fact that their containing assemblies are included in your program by default. To change this behavior at the command line, you can use the /nostdlib switch to force it not to include mscorlib.dll, or you can use /noconfig to have it ignore the entire default response file altogether. Also, I'm not too sure what you mean by system.dll, because the namespaces you mentioned are contained within mscorlib.dll. Also, I think by "external library", your instructor must have meant any 3rd party assemblies that would assist you in solving the problem. Anything that comes included with the .NET SDK would be more of a framework library. Unless your teacher is really harsh and wants you to reinvent the wheel :P
I hit this weird namespace issue when adding my first 'Service Reference' to a client project in Visual Studio 2010.
If my project's default namespace uses two or more parts, e.g. MyCompany.MyApp then when adding a Service Reference a Reference.cs file is created containing the namespace MyCompany.MyApp.ServiceReferenceName with a lot of auto-gen code with fully qualified names, e.g. System.SerializableAttribute, System.Runtime.Serialization.DataContractAttribute.
The Reference.cs file will be full of compilation errors because the compiler starts treating the System namespace as sub member of the MyCompany.MyApp namespace. You get an awful lot of errors along the lines of:
The type or namespace name 'Runtime' does not exist in the namespace 'MyCompany.MyApp.System'...
If I amend the namespace at the top of the Reference.cs file to something simple, e.g. MyCompanyMyApp.ServiceRefernceName then the compiler behaves and recognises the System namespace references as decleration of .net's System namespace.
I'm using a different workaround for now as I really want to keep my multi-part namespaces. My current alternative is to append global:: in front of the System namespace references to force the complier to do the right thing. In fact, if the 'Add Service Reference' wizard uses T4 templates I may just amend those to embed my workaround at the source.
Questions
I'd really like to understand what's going on here and why a multi-part namespace causes this issue. Presumably there's more to namespaces than I thought. Secondly, would really like to work out a better solution than performing a global Find/Replace every time I add a Service Reference or mucking around with some T4 templates.
I found the answer here somewhat unclear, so I thought I would add this as an example (I would do it in the comments but it looks better here):
So I have this as my default namespace:
namespace RelatedData.Loader
But I also add a class named:
public class RelatedData
{
}
Because the class name matches a portion of the namespace when it generates your proxy with Add Service Reference it gets confused.
The answer here was to rename my class:
public class RelatedDataItem
Ahh well I found the cause eventually.
I'm working against a very large third party WCF API and ... one of their namespaces is LameCompany.System (!!) Carnage then ensues...
Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
The lesson to learn here is when Visual Studio/.net compiler stops recognising the BCL's System namespace you have a namespace/type in your project called System. Find it, remove it, shoot the developer that created it.
I found that having a class name similar to your namespace causes this.
Try renaming your class name
I ran into a similar issue with VS2012 described by jabu.hlong and Simon Needham after minor changes in the client project that has the references to the WCF services after updating the reference to the services. I got lots of errors compiling the Reference.cs files generated and so on (the generated files of the XAML as well).
I have selected to reuse types from specific assemblies in my solution and got a similar problems with the namespaces.
The error I get is that the namespace of the reused assembly and the namespace of the generated types can not be found when used in the Reference.cs. Both namespaces have in common the first parts, as they are from the same solution. My namespaces in the solution are like appname.tier.technology.project. Both conflicting namespaces are Appname.Dto.Modulename (the reused assembly) and Appname.Client.Wpf.ServiceName (the namespace in the client project using the services for the generated types).
The problem arises after a minor change in the client project, when I created a new utility class in the namespace Appname.Client.Wpf.Appname. I choose that namespace because the Appname is also the name of a module in the client project. This seems to confuse the compiler and can not resolve both namespaces in the generated Reference.cs. After changing the namespace of the utility class to avoid using two identical parts in it and updating the service reference, the compiler errors in Reference.cs dissapears.
I tried different things (and tried different namespaces when adding the service reference), but nothing worked for me except this brute force fix - in my case it was OK but I am aware it's ugly (and needs to be repeated if you use "Update Reference" in the future):
Since the WCF service namespace is added to your default namespace, just search and replace all mentions of the newly added
MyNamespace.ServiceNamespace
with
ServiceNamespace
in the whole solution (use your own namespaces of course), including the auto-generated Reference.cs file.
Basically, the problem is a name conflict where one name is hiding another. A folder or class named "System" can do that, but if you also have a class with the same name as your project, you'll see the same thing. Sure, you can rename everything in the reference.cs, but it's probably better to rename your conflicting class.
I had folder in my project called "System" (yes, very stupid of me) and that caused some issues in the references.cs.
Renaming the folder (and the namespace), fixed the issue.
Here is how I solve this issue on VisualStudio 2017 trying to add a reference to a web service in a test project.
After trying adding the references, rebuilding, closing, reopening and spending some time on the issue, I noticed that VS had put the files it creates to reference the WS in a folder named "Connected Services".
I renamed the folder without the space then opened all the files in the folder and the csproj with a text editor, replaced all the occurrences of "Connected Services" to "ConnectedServices" and reopened the project.
I then added references to System.Runtime.Serialization and System.ServiceModel and everything now works fine.
This is a bug in Visual Studio (still is at version 2022). To fix, remove the namespace in the reference.cs file. So if your namespace is "myapplication" and your service is "myservice", you'll see myapplication.myservice in the reference.cs file. just delete "myapplication." everywhere and make sure it isn't auto-generated again (lest you have to re-delete everything).
I'm trying to create dynamically generated code based on user input (just like a mini-compiler). But my problem is that i need to use the PresentationFramework.dll assembly inside the dynamic code, and i don't know how to reference it.
I have already tried Assembly.Load() and Assembly.Loadfrom(). But all i get is an error saying:
"Assembly not found"
I am used to doing this with the IDE (right click references and then add), but now i need to find some way to do this through code.
I need the assembly to use System.Windows.Shell to create custom jumplists.
This isn't just happening for this specific assembly, but for several others too. But this is the most important one, so if someone could help me with this i would be thankful.
So the baseline is: I need to use the namespace System.Windows.Shell. I need to reference this namespace fully through code (no IDE). How can this be done? And is it even possible?
I'm using Visual Studio 2010 Ultimate (C#).
Thanks in advance!
It depends on the version of PresentationFramework you want when you need to add it as a reference. Basically, you will find it in :
\Program File\Reference Assemblies\Microsoft\Framework
(for 64-bit compilation, or 32-bit on a 32-bit OS)
or
\Program File (x86)\Reference Assemblies\Microsoft\Framework
(for 32-bit compilation or 32-bit on a 64-bit OS)
These are only the root folders. From here, you can go for example in "v3.0" or ".NETFramework\v4.0" for example.
So you just need to add a reference to a full "[path]\PresentationFramework.dll" instead of just "PresentationFramework.dll", for example:
"C:\Program File\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\PresentationFramework.dll".
Here is the answer straight from MSDN:
If your project references any
assemblies, you must specify the
assembly names as items in a
StringCollection as the
ReferencedAssemblies property of the
CompilerParameters you use when
invoking compilation.