I have developed a lot of class library projects in VS 2012 to be used in Windows Forms and Web forms applications.
The question is simple. Do I need to deploy the DLL file itself together with the XML file that is created?
For example, the class library project is called DataWare. Upon building, I got 5 files in Release folder (this project reference Entity Framework):
DataWare.dll
DataWare.pdb
DataWare.dll.config
EntityFramework.dll
EntityFramework.xml
I know that ".pdb" file contains debugging information, so there is no need to deploy. The ".config" file is not taken into account. Instead the App.config or Web.config are.
Regarding this, I think I have to deploy just DataWare.dll and EntityFramework.dll.
However, the main doubt is if I need to deploy EntityFramework.xml as well.
Regards
Jaime
The XML file contains the doc comments for the public types & members in the assembly.
You only need it if you want Visual Studio to show documentation in IntelliSense.
If you're deploying a consumer-facing app (as opposed to a developer-facing reusable library), you do not need it.
No, in most cases you do not need it. If there is an external DLL that needs to be copied local and referenced using the config, then you might need to, but that is somewhat rare.
Related
I've just inherited a web application whose source has long been lost (originally written in 2010 and shelved). The application has a few .dll assemblies that related to the application itself e.g. "applicationCORE.dll", "applicationBI.dll", "applicationDATA.dll" and "application.dll"
I've seen this question and the suggested tool (Just Decompile) is brilliant and created a .sln and .csproj file for the first assembly that I decompiled. My question is how do I merge the various projects that would be created through decompiling with the compiled web application files (.aspx) also, how do I resolve the references in the .aspx files i.e. referencing the codebehind file that no longer exists e.g. "default.aspx" references "default.aspx.cs" while the decompiler creates a "default.cs" file. Is it safer to rename the .cs file or should I update the reference?
Finally, will each dll appear as a separate project within the solution?
I realise this may be perceived as a duplicate question however there doesn't appear to be a resource online that walks a developer through the process.
Following David's advice, I managed to get the application running from decompiled assemblies. Here's the process I followed to get it working
I had already decompiled the various assemblies into projects using a Reflector (on a trial).
I created a blank Web forms application in Visual Studio
I added the .aspx pages from the website to the project through visual studio
Then added the .cs files from the decompiled 'application.dll' project (since this is the website project within the solution. Some files had to be renamed to match the codebehind references in the `.aspx. files
Each additional project e.g. applicationCore.dll was then added to the solution
Each project's references needed to be updated and references to the newly added projects must be added to the startup project
Since the website was built so long ago, there were 1,000's of syntax errors. The easiest way to resolve them was to use Notepad++ and the Find and Replace. To be safe, I did this file-by-file by following the errors from Visual Studio rather than a batch find and replace
When trying to build I noticed errors where required assemblies were missing so I changed the build output directory of the sub-projects to the bin folder of the web project
I added the connection strings and settings from the original website's web.config. I did this line by line to make sure I didn't break anything and so that I could trace the result of each addition
Finally I had a successful build!
Additional Steps
There were also syntax errors which I assumed were due to the decompiling process. Some external references needed to be added and there were slight changes due to the age of the project e.g. asp:AjaxScriptControl changed to asp:ScriptControl (after adding the package using Nuget). I also had to install Crystal Reports for this application and will have to purchase a Telerik licence as there are UI components being used (although I'll see if I can use an open / native alternative as I work through the app).
I've logged in using credentials (I did have to set the correct start page) and tried a few basic CRUD operations. There are silly issues that have to be resolved e.g. the authentication doesn't work properly and there's no redirect if you access a protected page but these things are relatively minor compared to the issues I faced initially.
What I must say is each error was resolved using questions and answers from this site! This was all completed in just under 6 hours.
I am using Visual Studio 2008
I have two applications (AppA and AppB) that I what to be installed using one msi-installer.
Both applications have reference AppC.
This is what I did:
I created Setup Project
I created two subfolders inside of Application Folder (AppA and AppB)
I added Project Output for AppA into related subfolder
I added Project Output for AppB into related subfolder
Problem: AppC did not appear in subfolder for AppB. It looks like dependency can only appear once.
Could please tell me how to resolve this?
You should be adding "Primary Output from AppC" specifically to each of the application folders. This version of VS Setup does not appear to detect that the same dependency needs to be included in two application folders.
There are a lot of recorded problems with the VS Setup and Deployment project, especially in regards to dependency detection. Also consider that MS has stopped shipping this project type, and has chosen the ISLE as its replacement (I would recommend using WIX instead - its free and is a more modern toolset when compared to Flexera's offerings).
A merge module is overkill for a single assembly. If you had a package of assemblies that need things like COM exposure or other group behavior things that you dont want to repeat (and possibly get wrong), then a merge module is more appropriate.
I'm new in .Net and working with two projects in c# a class library project(dll) and a website asp project.
I need to read some properties from a file .resx that is in the App_GlobalResources folder of the website.
Is there a way to read these properties in the .resx website file from a dll assembly more specifically in the method onPreRender??
Thanks for you attention
It sounds to me that you are having some problems with structuring and dependencies in your solution. (Trying to reference the website from a DLL)
Generally speaking, your DLL should not need to access the resources of the website on its own - you should only pass them in through as parameters when calling various methods that are contained in the DLL itself.
Have you thought about migrating the resource file to the DLL?
That would allow both DLL and the website to read from it.
Another option would be to migrate the setting you need to the .config file which you can read by using the ConfigurationManager class ( MSND Link )
You should be able to use it like this, even from your Code repository project:
string settingValue = ConfigurationManager.AppSettings["YouSettingNameHere"].ToString();
However, if you really want to keep your current solution structure you can follow the answer that Pavel Chuchuva gave on a similar question here.
hopefully this is a quick one. If I have c# class files on WebsiteA.com - can I reference them in WebsiteB.com? Both sites are on the same server, so I was hoping to reference them on a static address? (d:/inetpub/wwwroot/websiteA-com/app_code/MyClass.cs)
Is this possible? Or - do I have to copy the class file to WebsiteB.com and simply use that?
I just want to avoid repetition when I need to make any changes - avoiding changing both sites.
I've built both sites in .net 4 using visual studio 2010 express.
Thanks
If I were you, I would take all the classes needed by both websites and create a Class Library Project (DLL). Then reference that project in each website and use the classes. This means each site will be deployed with the same DLL but you will have a single project for common classes.
Hope this helps (I know it's not strictly the answer)
Sure you can.
I don't think that adding the class from the app pool of the IIS folder is a good idea though.
I believe it's a better practice though to make a class library as a separate project called for example Shared and reference it in both projects.
in Visual Studio you can "Add existing" then choose the "Link" option to add source code from another project
this can be much easier to manage than a shared class library - you can even include the same code in wildly different projects (compact framework, different versions of dot net, etc.)
There are 5 console apps working off each other's outputs and are separately installed on my computer (C# 4.0, I am the author) . Management would like to distribute this suite of apps to other users, but aren't thrilled about asking non-tech users to install/configure 5 separate applications. Is there any way I can compile each program down into a .dll and reference them through a single master application?
Q. The main issue seems to be that you don't want 5 separate installation steps?
A. Make an installer for the suite :) Use any MSI builder (WiX, Visual Studio setup projects, InstallShield, and many others; Heck, you could even do an XCOPY deployment in most cases)
Q. How do I directly invoke these programs from within a single process?
A. Options:
Load the assemblies in your AppDomain.
Use a separate AppDomain in case of name(space) conflicts or version conflicts
Q. How do I optionally 'hide' the presence of the external console apps from view
A. Look at ilmerge to possibly combine the 'external' assemblies so they aren't visible anymore. If you can't use ilmerge (conflicts, or e.g. WPF apps) you might embed them as resources and load them on demand as per 1. and 2. above
Update: https://libz.codeplex.com/ is a nice looking project that makes this easy (haven't tried it myself)
Just because each of them is a separate .exe file doesn't mean you can't treat them as one application. And they don't have to be installed or configured separately either.
But a much better solution would be to rewrite each of the applications, so that they expose classes or interfaces that can be used without actually running the application. This way, communication between the parts is going to be much easier.
In .Net, the only difference between .exe and .dll is that you can run .exe directly. But you can treat both as libraries, so you can use functionality from one .exe in another .exe. Another step might be separating the core of each application into a .dll and make the .exes just deal with input and output. With this, the combined application wouldn't have all the code that it doesn't need from the other ones.
Its possible if every assembly is using different class names. Just include the whole source code when you compile the final version in one project.
Go to Project's properties, Application and change OutputType from Console to Class Library.
EDIT
Would like to express my doubts on architectual desicion like this, correct me if I'm wrong in my thinking:
Having different EXE applications standalone, I presume, you have different Applications that works standalone.
What advantage you gain by converting them in DLL's and puting them together in one master app ? Why do not just use this EXEs with one master app and launch them ?
In this way you leave as is it already working + you add a layer (master app) so for final user all this seems like one single app.
That is possible - several options:
you put the functionality of each console app into a separate class within the same project and have one "master console app" provide their functionalities
you put the functionality of each console app into a separate class each in different project with DLL as target, then you reference those DLLs as needed from your "master console app"
Note: IF you go the DLL route you could embed the DLLs into the console EXE using the technique from http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
With both option (all in one EXE or EXE + embedded DLLs) you can just make an XCOPY deployment if there are no other dependencies...