I have a class library lets call it UtilityLibrary.
I have a console application. So I right clicked on my solution and added an existing project (UtilityLibrary). I noticed that I can change the code of UtilityLibrary from within my console application.
The issue is if I had added UtilityLibrary to another application and the code had been changed it could causes issues. I was trying to avoid adding a dll reference so thought I would add a reference to my project however I am worried about the code being edited.
Have I added the reference to my project incorrectly?
If you where to check the Debug or Release folder if your console application you should see a UtlityLibrary.dll file, which would still mean that you are, in the end, adding a DLL reference (visual studio will do it for you).
Since you do not want to allow external entities to change your application, simply add a DLL reference instead.
Just to clarify, you can only change the source of one DLL from another application becuase visual studio can find the source files and makes them available to you.
No. You have done nothing wrong. And you can't just change the code of the compiled assembly. You are utilizing a feature from Visual Studio. Since you've build on this machine, and the PDB's are included, it can tell the assembly originated from that source code on your machine. So it allows you to edit it.
These edits don't come in the compiled assembly immediately, you have to compile it again in order to be in the assembly. (Note that you can extract the source code from any .NET assembly by using Refactor for example)
Related
I'm writing applications and libraries simultaneously, and whenever I update a library it's a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instance for each library and application. After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
Would like to understand why this happens and if something can be done to make this work more smoothly?
Not sure if it's relevant but most of my applications I write in VB.NET and libaries in C# (as I'm in progress of changing everything to C#). I also have C# files from the libraries open in the consumer application VS, as it pops up during debugging. I also reference library dlls in the library project /bin/Debug folder, because I'm making a lot of changes at this point of development.
Warning 1 Namespace or type specified in the Imports 'somelibrary'
doesn't contain any public member or cannot be found. Make sure the
namespace or the type is defined and contains at least one public
member. Make sure the imported element name doesn't use any
aliases. 'local path'
..
Error 72 Unable to load referenced library 'path\somelibrary.dll': The
process cannot access the file because it is being used by another
process.
I'm writing applications and libraries simultaneously, and whenever I update a library it's a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instances for each library and application.
This is the fundamental source of your problem. Visual Studio does not like it when things outside it's control change. You should have a single solution open with all the relevant projects included in it. Then when something changes, all the projects which depend on that project will automatically be rebuilt. (At least, that's the default.)
After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
I don't think it has anything to do with how many times you clean and rebuild it, but how long it's been since you last made a change - you have to wait long enough for the VS instance building the dll to release the lock on the file, before the VS instance that is using it is able to access it.
When you build a project you lock up the .DLL file in the project you build it from, because that is the version of the assembly that the library instance of visual studio will use - however you are referencing that very same library in another process hence the reason you are seeing the error.
You have two options, keep having two instances and then close the two instances open them again and it will be fine.
What you are better off doing is adding the project itself you are referencing (and are getting the error for) to your solution. Then instead of referencing YourProject/bin/debug/assembly.dll add a reference to the local project via the Projects tab. This will then keep one process referencing the appropriate assemblies that it needs.
For every project in the solution check the project settings -> Compile tab -> advanced compile options... -> target framework(all configurations), see if they are all (for example) .NET framework 4. having different or the wrong framework might cause the problems you're having right now
There is a Github project for a C# library that I'd like to use. Is it more conventional to include the source as a separate project in my Visual Studio solution and build the dll as part of the regular compilation process, or to build a dll separately and include just that in my project reference?
Unless you need to modify the source, use a DLL. Don't forget to mention the license and the source repository location (home of the Github project)
Both the options are equally valid and depends upon how often you require the change the source code.
If you really need to change the source code then you should add the
source code to your project otherwise just adding the reference of the dll will save your
compilation time.
I have seen both approaches.
Mostly I've included 3rd party code into the solution if I intended to modify it a little, or at least I assumed I would.
All other cases, Dll works fine.
In C#, I made a ClassLibrary that has one Namespace and one Class.
I saved it and build it.
in other Projects, when i use it, I add it to my references by browsing to the .dll location.
But The Problem is that its name is not showing up in the Intellisense.
i.e when I: using ... my dll doesn't show ..
I'm Importing the library to a ConsoleApp.
both of the App and the library target Framework is .NET Framework 4.0
and I made their Assembly Version 4.0.0.0 so they're the exact same.
is there a setting or something that I'm missing ?
how can i make it pop up ?
I'm using VS2010 Professional
Thank you for your help
Maybe this be usefull, I was having a similar issue, I have a Web project, add the reference to a Class Library by selecting the project, but if I made a change on the class library, I can´t see that change on the intellisense of the Web Project, after try many things, I see that in the recently added reference, the value of the option "Local Copy" was set "True", then I change it to false and everething works!
I had a similar issue but in my case it was a property on the class. If you go to the file properties and look for a Build Action. Somehow mine was set to Content it had to be set to Compile.
I am using Visual Studio 2013. I hope this helps someone else.
Is the namespace for your assembly different than the namespace for your currently open project? I've had times when the current project and an assembly share the same namespace path the intellisense can mess up.
In general, Visual Studio is pretty good about intellisense generation, especially for C#. But sometimes there are some interesting conditions regarding ambiguities, and especially mixing project types where it just doesn't quite work.
Placing your content in the same namespace makes me wonder if you've actually fixed the problem (it may just be autocompleting the namespace in the currently loaded project rather than the assembly), but if it allows you to continue working, then go with it!
Right click on project on which you add reference of your dll/project select menu project dependancies and select/MarkCheckBox for reference project/dll. then it will work fine.
If the class library project had its name changed after creation, then intellisense may fail finding it due to directory issues, I believe.
I created my class with the generic "ClassLibrary1" or whatever, and then later changed the default namespace, class name, and project name inside of VS2017. I closed VS2017 and changed the directory name to match my default namespace, and then re-associated the project file in VS2017, and then re-added the reference in my main project file.
All seems to be fixed now.
I have a wpf Application in which I am trying to reference a class library i have created.
I have added a reference to the .dll
And i have added the using statement to my file, and the intellisense actually sees the new namespace.
Then in my code I am able to create new objects of classes in my added .dll just fine. the intellisense sees all the methods ect..no problem, no errors.
when I try to build my wpf application, all the sudden I get the type or namespace cannot be found error on my added dll.
Then i get errors whenever i am trying to create objects from that .dll.
I don't get what is happening.. why does it work before I build, but when I build it decides it doesn't know where that .dll is i am referencing?
Also i have gone to that class library i am trying to add, and mades sure it builds with no errors.
The most common cause of this is that your .DLL targets the full .NET Framework, but the WPF Application targets the Client Profile.
For example, if your library targets .NET 3.5, make sure your WPF Application targets the full .NET 3.5 or 4.0 framework, not the client profile.
A few thoughts on this matter that you can try:
Check that a lower version is not calling a higher version assembly (e.g. .NET 3.5 project is not calling a .NET 4.0 assembly).
Clean -> Build (or Rebuild)
Manually delete bin/obj folders of both caller and calling projects. This forces everything to be built - the 'hard ' way. This may sound redundant, but has worked for me a couple of times.
Restart VS - sometimes, there is just no explanation.
Reboot - when nothing else works, give it a break and try again.
You can Copy any .dll files from other project,
two .dll files.
eg: A.dll,A.pdb
and Rename this two files to your project's name.
Then you can rebuild this project.
If you're getting this without a DLL - just a code file check it's set to compile. In Visual Studio 2013 I keep adding code files and it sets the Build Action (found under Advanced section of Properties of the code file to "Content" rather than "Compile". Change this.
Sometimes an explicit naming of the assembly which contains the namespace is required.
xmlns:myns="clr-namespace:MyNamespace;assembly=MyAssembly"
I don't know why it is sometimes required.
I'm getting System.IO.FileNotFoundException: The specified module could not be found when running C# code that calls a C++/CLI assembly which in turn calls a pure C DLL. It happens as soon as an object is instantiated that calls the pure C DLL functions.
BackingStore is pure C.
CPPDemoViewModel is C++/CLI calling BackingStore it has a reference to BackingStore.
I tried the simplest possible case - add a new C# unit test project that just tries to create an object defined in CPPDemoViewModel . I added a reference from the C# project to CPPDemoViewModel .
A C++/CLI test project works fine with just the added ref to CPPDemoViewModel so it's something about going between the languages.
I'm using Visual Studio 2008 SP1 with .Net 3.5 SP1. I'm building on Vista x64 but have been careful to make sure my Platform target is set to x86.
This feels like something stupid and obvious I'm missing but it would be even more stupid of me to waste time trying to solve it in private so I'm out here embarrassing myself!
This is a test for a project porting a huge amount of legacy C code which I'm keeping in a DLL with a ViewModel implemented in C++/CLI.
edit
After checking directories, I can confirm that the BackingStore.dll has not been copied.
I have the standard unique project folders created with a typical multi-project solution.
WPFViewModelInCPP
BackingStore
CPPViewModel
CPPViewModelTestInCS
bin
Debug
Debug
The higher-level Debug appears to be a common folder used by the C and C++/CLI projects, to my surprise.
WPFViewModelInCPP\Debug contains BackingStore.dll, CPPDemoViewModel.dll, CPPViewModelTest.dll and their associated .ilk and .pdb files
WPFViewModelInCPP\CPPViewModelTestInCS\bin\Debug contains CPPDemoViewModel and CPPViewModelTestInCS .dll and .pdb files but not BackingStore. However, manually copying BackingStore into that directory did not fix the error.
CPPDemoViewModel has the property Copy Local set which I assume is responsible for copying its DLL when if is referenced. I can't add a reference from a C# project to a pure C DLL - it just says A Reference to Backing Store could not be added.
I'm not sure if I have just one problem or two.
I can use an old-fashioned copying build step to copy the BackingStore.dll into any given C# project's directories, although I'd hoped the new .net model didn't require that.
DependencyWalker is telling me that the missing file is GPSVC.dll which has been suggested indicates security setting issues. I suspect this is a red herring.
edit2
With a manual copy of BackingStore.dll to be adjacent to the executable, the GUI now works fine. The C# Test Project still has problems which I suspect is due to the runtime environment of a test project but I can live without that for now.
Are the C and C++ DLLs in the same directory as the C# assembly that's executing?
You may have to change your project output settings so that the C# assembly and the other DLLs all end up in the same folder.
I've often used the Dependency Walker in cases like this; it's a sanity check that shows that all the dependencies can actually be found.
Once your app is running, you may also want to try out Process Monitor on the code you are running, to see which DLLs are being referenced, and where they are located.
The answer for the GUI, other than changing output settings, was the addition of a Pre-Build Step
copy $(ProjectDir)..\Debug\BackingStore.* $(TargetDir)
The answer for the Test projects was to add the missing DLL to the Deployment tab of the testrunconfig. You can either do so by directly editing the default LocalTestRun.testrunconfig (appears in Solution under Solution Items) or right-click the Solution and Add a new test run config, which will then appear under the main Test menu.
Thanks for the answers on this SO question on test configurations for leading me to the answer.
The reason why this happens is because you either are loading DLLMAIN from managed code, before the CRT has an opportunity to be initialized. You may not have any managed code, be executed DIRECTLY or INDERECTLY from an effect of DllMain notifications. (See: Expert C++/CLI: .Net for Visual C++ Programmers, chapter 11++).
Or you have no native entrypoint defined wahtsoever, yet you have linked to MSVCRT. The CLR is automatically initialized for you with /clr, this detail causes a lot of confusion and must be taken into account. A mixed mode DLL actually delay loads the CLR through the use of hot-patching all of the managed entry point vtables in your classes.
A number of class initialization issues surround this topic, loader lock and delay loading CLR are a bit trickey sometimes. Try to declare global's static and do not use #pragma managed/unmanaged, isolate your code with /clr per-file.
If you can not isolate your code from the managed code, and are having trouble, (after taking some of these steps), you can also look towards hosting the CLR yourself and perhaps going through the effort of creating a domain manager, that would ensure your fully "in-the-loop" of runtime events and bootstrapping.
This is exactally why, it has nothting todo with your search path, or initialization. Unfortunately the Fusion log viewer does not help that much (which is the usual place to look for .NET CLR assembly binding issues not dependency walker).
Linking statically has nothing todo with this either. You can NOT statically link a C++/CLI application which is mixed mode.
Place your DLLMAIN function into a file by itself.
Ensure that this file does NOT have /CLR set in the build options (file build options)
Make sure your linking with /MD or /MDd, and all your dependencies which you LINK use the exact same CRT.
Evaluate your linker's settings for /DEFAULTLIB and /INCLUDE to identify any possiable reference issues, you can declare a prototype in your code and use /INCLUDE to override default library link resolution.
Good luck, also check that book it's very good.
Make sure the target system has the correct MS Visual C runtime, and that you are not accidentally building the C dll with a debug runtime.
This is an interesting dilemma. I've never heard of a problem loading native .DLLs from C++/CLI after a call into it from C# before. I can only assume the problem is as #Daniel L suggested, and that your .DLL simply isn't in a path the assembly loader can find.
If Daniel's suggestion doesn't work out, I suggest you try statically linking the native C code to the C++/CLI program, if you can. That would certainly solve the problem, as the .DLL would then be entirely absorbed into the C++/CLI .DLL.
Had the same problem switching to 64-bit Vista. Our application was calling Win32 DLLs which was confusing the target build for the application. To resolve it we did the following:
Go to project properties;
Select Build tab;
Change 'Platform target:' option to x86;
Rebuild the application.
When I re-ran the application it worked.