I have a console application that builds some default classes for me from a database. When the files are built, I want to be able to refresh my folders and see the new files in my class library.
However no matter what I do the files don't show up unless I go in and manually add existing files. Is there a way for VS2010 to look at the file folder and add in anything that is in that folder to the project? For example:
Folder > File1.cs, File2.cs, File3.cs, File4.cs
VS2010 sees
Folder > File1.cs
How can I make VS2010 show these new classes?
Your problem is that you will only see files that are included and referenced in your .csproj file. This is by and large a good thing because it gives you ultimate control over what is taken into account in the project or not. This is causing you a problem though, because the created files which are inserted into your project directory aren't being referenced. As you have mentioned you can include the files manually, but I understand that you wish this process to be automatic.
The best way to resovle this in my opinion is instead of having a project create the files, use design-time T4 templates. Design-time T4 templates are files which resemble pre-Razor ASP.NET views, which allow code generation within your project. You can access your database, format your classes and then output .cs files directly into your project without building it. This is extremely convenient becuase it lets you work on catching compile-time errors that may come up based on the output without having to do a complete build.
More information about using T4 can be found here.
And a good walkthrough can be found here.
Haven't tried this personally, but you should be able to do it using this..
First gain a reference to your project using your apps' solution, then with the Visual Studio automation framework (DTE):
ProjectItems p = Project.ProjectItems;
p.AddFromFile("File1.cs");
Taken from: http://msdn.microsoft.com/en-us/library/envdte.projectitems.addfromfile.aspx
I would read further into it.
Select the project where you can find your file
On top of your solution explorer you can select "show all files"
Select your files and include
Adding them automatically can be done from another app or script by modifying your projects .csproj/vbproj file
<Compile Include="My Project\MyClass.vb" />
This must be done in the correct itemgroup.
I think this is not directly possible. You may write a template file (t4) in order to create you cs files and they will be added to project when the transformation file is run.
In order to run the transformation file after / before build, you may write a pre/post build event.
That will require you to create a VS add-in.. you can find an example here...
Okay so I have a console application that is building some default classes for me from a database.
Can't you let this application write all classes in one file, say Proxy.cs or Entities.cs. Then every time you regenerate the file and rebuild the project, you can access the new classes.
Related
I'm a little bit stuck. I've just checked out an open source project from google code for something and it's a nice little C# code base.
However there's no solution file or anything. I'm not really sure how to compile it from here on as I've always worked within a solution.
I can't seem to find a solution online and was just wondering if someone could tell me how to compile a number of .cs files together to run, or how to create a solution from them.
Create a new project. You will need to decide whether it should be a class library, console application, etc. depending on what the open source project is supposed to be.
Right-click on the project and select Add -> New Item.
From the file dialog, select all of the .cs files you wish to compile.
If the project is not a class library, then right-click on the project and select Properties. Go to the Application tab and specify which class contains the startup object.
Build the project and see if it works.
Contact the project maintainers and ask them to include a proper project file. Offer to send your .csproj file if it works.
It's also possible to compile manually on the command-line with the C# compiler, but this would be more difficult.
Create an empty solution and add those files to an empty project [Need to figure out project type though].
If you project have .csproj file then create empty solution and add this project to the solution using .csproj file.
If you have'nt .csproj file then you have to figure out the the type of the project and then add these file to the project to make the solution.
I'm writing a C# project which I want to compile both under VS2010 and VS2012. I want to have two different .csproj files for that, even though VS2010-project can be directly included in VS2012-solution. I want two different project files because of different target .NET-versions.
Additionally, I want both projects to be named the same within different solutions for VS2010 and VS2012. The both should share the same .cs-files and, possibly, some resources.
Easy task? Strange thing, but I don't know, how to do that properly.
First approach, doesn't work: name project files as MyProject10.csproj and MyProject12.csproj, leave both in the MyProject folder. But in this case they are displayed in solution as MyProject10 and MyProject12, not simply MyProject. If I rename one to MyProject in solution explorer, it automatically renames the corresponding project file.
Second approach, works, but has drawbacks. Move project files into different subdirectories, named VS10 and VS12, manually change include paths in .csproj-files, adding ..\ as a prefix. In this case I see strange shortcut-like arrows under the icons in solution explorer.
The only bad thing for the second approach is that when I add new files in the project using solution explorer, this file is placed in the VS10 subdirectory, not in the root project directory. But it seems like project directories for .csproj-files are the directories containing the file by design, and I use the dark side of the force which I really don't want to do.
Any better ideas?
Worth giving a try is changing the name of the output assembly in both projects to one and the same. The project files are still going to be different, but the output assembly will be with same name. Also be carefull where is the output directory. I think this way you can sovle your problem.
Is it simple or even possible?
Why: Following my other question and using this approach, now I would like to simply embed the source file to the resources so I can copy it to the temp folder while the application is running - and keep the application as a single file.
I assume using a pre-build event is the best way to do this. If so, how would it be done?
EDIT: I'm asking about adding it before building because I also assume it won't be automatically updated if I add it manually once and then change the code after.
I recently went through this same issue when developing an examples suite for a .NET control which had to display its own example source code in the application.
The approach I ended up with was as follows.
I created a batch script (run in pre-build) to copy all the code files under /Examples/* to another folder in the solution Resources/ExamplesSrc/*
I then included all these files under Resources/ExamplesSrc/* in the csproj and saved it.
The next step was I set all the files under Resources/ExamplesSrc/* as embedded resource and committed the change to SVN. I did not commit the examples (generated) to SVN, just the modified csproj and batch file.
The effect when developers checked out was that they had (!) icons on all the resources (they were not on disk, but the csproj was looking for them), however as soon as they built the generated files appeared and all was well. This approach also worked with a build server (Team city) and the examples suite can now load and browse its own code via embedded resources.
One caveat you should be aware of. There is a quirk (by design apparently) in VS2010. If an embedded resource has ".cs" in it (i.e. any code file!) it cannot be loaded from the assembly using Assembly.GetManifestResourceStream(). To work around this all source files were renamed in the batch copy step from *.Xaml.cs to *.Xaml.c.txt, from *.cs to *.c.txt
Hope this helps!
Turns out I don't need to (re)add the source file each time I build the solution!
When I add it manually once it becomes a "Text" file on resources - and I can easily access it as a string using Properties.Resources.SourceCode (having the file named "SourceCode.cs"). And yes, it is updated automatically since the resource property "Persistence": the file is linked at compile time.
I'm still learning the basics of how VS2010 sees the world. Apparently, you can optionally "include" a file in a project. I'm a bit confused by this: If a file is version-controlled, AND the file is within the project directory, shouldn't it implicitly be "included" in the project? If not, what's the use case where a version-controlled file in the project directory should NOT be included in the project?
=== Addition ===
Based on the answers I've gotten so far, maybe I should rephrased my question: What does it mean for a file to be "included" in a project?
A project needs to know about files in order for compilation and distribution to occur. Just because you have a file that's under source-control, doesn't mean that it will be compiled if the project is unaware of it.
Also, you may want to include files as part of a distribution package. We do this quite often for our web projects that we distribute using web app gallery.
Conversely, you could have documentation or sql scripts that you version control, but do not want them to be part of the project.
EDIT: In answer to your update, what it means for a file to be included in a project is that the file is actually added to the .csproj or .vbproj file and will be used during compilation and/or distribution. VS does differentiate if the file is Content or if it needs to Compile it. This can be seen by clicking on the file in Solution Explorer and looking at the Build Action property.
No, you don't want random files that happen to be in the project directory included in source control.
We do sometimes put documentation (pdfs) or drawings/schematics in the project folder and under version control but you don't need them inside the visual studio project (especially when they are not being distributed because they are for internal use only).
Excluding the file from your project can be useful if the file is related to the project but not necessarily needed in the solution.
Example
If I need some test XML for an application that i'm writing; that is designed to normally be pulling this from a WCF service, it can be useful to keep that file in the directory for a development environment where I use IO to get the XML for testing, but I don't necessarily want it in my solution which is source controlled.
When you exclude a file from a project is no longer compiled or embedded, then when you want to include it again you can do so without having lost your settings.
If you e.g. copy a file (containing a helpful class which want to have in your project) into a folder of your project, then you will see ... nothing. You have to check the option "Show all files" of the solution explorer and the copied file can be seen, but it is still "greyed out". No you can choose the menuitem Include in project and that file will be integrated in your project and a pending change (add) for your source control is added too. Visual Studio doesn't include all files it can find in the project folder automatically to the project - and that is a good feature.
One of my colleagues explained to me a scenario in which a version-controlled file should NOT be part of the project. Here's the idea:
A developer writes some new code.
The code is experimental, and not intended to be part of the normal build.
The easiest way to exclude the file from the build is to NOT include it in the project, but still version-control it.
This way, the file can be shared with other developers, but not break the build.
I have a annoying build process from using System.Addins API with ClickOnce. Using System.Addins requires a specific directory structure, and the main project does not reference the adapters, view, and contract directly, which doesn't work well with the ClickOnce architechture.
The annoying part with the build process is that I have to copy, via post build event, the .dlls from the add-in components into the directory of the main app project, then reference those files manually from the main project, so that ClickOnce will include them. Firstly, this takes 2 iterations of build to get it to build correctly, secondly, it interferes with source control (I have to exclude the copied add-in dll files from source control or any changes made to them would require checkout).
So, my question is, is there a way around this hack? Something more elegant?
I can't fully answer your question, but it appears you are creating ClickOnce deployments through Visual Studio. I would ditch that method and use MageUI instead. It's a stand-alone executable that can be found in the framework SDK that will generate your application and deployment manifest files. It comes with a gui version (mageui.exe) and a command line version (mage.exe).
Mage may not get rid of your post-build event but it should do away with having to reference the files to get ClickOnce to see them.
Thanks for your input, I am currently doing it the way you mentioned; creating the folder in my project, and include the dlls that I need. It works, but it's an ugly solution, and it interferes with Source Control.
I'm aware of the limitations of ClickOnce, I was hoping there may be a way around it. For example, I read somewhere that I can use deployment projects to create the appropriate dependencies needed in a specific structure. The problem with that is once it is deployed to the public, there is no easy way (within ClickOnce) to update those dependencies.
The solution I use is to have a single output folder for all projects. Every project puts it's own files in the correct subfolder. The application bootstrapper project puts his dlls also in the output (root) folder. When you then create a click-ones for the bootstrapper, it will take all the content from the output folder.
The hardest part is to actually get all the dll's in the right place (and have every dll only once)
I solved this problem by adding the pipeline assemblies as content into the main solution structure.
To do this, change the output folder from (/bin/debug /bin/Release) to something else. I used ../lib otherwise you would get a visual studio cannot reference this file error.
Create the pipeline folders in your main solution
\AddInSideAdapters
\AddInViews
\Contracts
\HostSideAdapters
Right click on each of the folders and click "add existing item" change to view all files and then browse to your ../lib (or wherever you have the output set) and then pull down the add button (click the down arrow) and click "Add as a Link".
Right click on each file and set it to Content.
This will create a refresh file pointed to your assemblies and they will be included into the clickonce manifest.
ClickOnce do not let you install the software where you want. It will install the binary and dlls in the documents and settings. You can in your project properties go in the Publish tab and select Application Files to select additional file to Include. If the System.Addings require dll in a specific folder relatively to your assembly, you might just create the folder in you project and includes from here the dlls. This might works. If not, I do not have "hack" or other solution, clickonce is great but limited with some functionalities.