I currently have a requirement where I need to validate that all the files in a folder structure which are in SVN to see if they are up to date. Is there a way to do this using the svn artefacts that are held in the same directory as the file without interacting with SVN?
Apologies, this appears to need some further explanation...
I'm iterating through the projects loaded within a solution and can access the corresponding files on the file system. I need to check
a) if corresponding files on the file system match the latest revision if the file is under source control and
b) if any or the files or projects have not been added to the SVN.
This is essentially a validation check prior to calling a build server to start a build in case a user has forgotten to check in some changes, new files or new projects to a solution. The build server retrieves the code directly from the source control.
Do you ask how to detect what files stored in SVN folder(s) are changed?
You ask to do that without interacting with SVN, but I would recommend avoid this because file or folder structure can be changed by Subversion team in future.
Try to use SharpSVN I use it in one of my projects. It handy, stable, has nice API and actively developed.
Also check comments in your question. Anyway you can check source code of SharpSVN to undestand how to make it by yourself
Related
I want to invoke custom action to execute set of .sql files against given database. I am able to do that using custom action code(in c#) if I hardcode path of folder where my sql files are available.
I want to put this sql scripts folder in same location where my .msi is present. How can I access/find this folder-path from custom action during the time of installation?
I am using Wix 3.6.
I am using dot net bootstrapper to create my setup.exe.
The SqlScript element in the WiX toolset may do a lot of what you are asking for. It actually stores the scripts as Binary streams in the MSI instead of relying on files relative to the MSI. This is an important design decision because there are many cases where your MSI will execute but not have access to the original source media so it would not find the scripts. For example, repair operations can be launched from the cached MSI package. If your custom action was to repair, it would need the original media to get the scripts. This is not very desirable.
If you really want to go down this path, then you'll want to look at using the SourceDir directory to get the "source location" of your MSI. As noted above, the source media may not always be available and SourceDir will be blank in those cases. To force SourceDir to be set, you'll need to add a ResolveFiles action. Be careful when scheduling ResolveFiles because that will require the original media. If that can't be found, the user will be prompted to insert it again.
The worst case of poor sequencing of ResolveFiles is a prompt from source when the user is attempting to uninstall their product. User's are trying to get your application of the machine and they are prevented unless they can find how they originally installed it. Good way to really upset your users. :)
I highly recommend looking at the SqlScript element instead or the source code if you are really interested. It's in the WiX toolset at src\ca\serverca (look for files with "sql" in the name below there).
I have formed a number of source code files as my library. For example, I wrote LinqExtension.cs providing Median() function.
Now I'm working on a project which needs LinqExtension.cs. As usually, I link the file to the project. As introduced here. The reason that I link files rather than copying them is to keep the files at a single location. If I modify a file, all dependent projects get affected.
I also add the project to Subversion and upload to and download from Google Code. The linked file is not under version control.
I work on the project at home as well as at office. I hate copying the linked file to my office, which makes the file not single.
I figure out a solution that add <Compile Include="http://www.example.com/LinqExtension.cs"/> to csproj file so that the file only exists on the Internet. Once I upload a new verison of the file, all dependent projects get affected. Unfortunately the solution doesn't work.
Any other suggesions or better practice?
A better way would be to share your core library at the binary level, rather than at source code. You could set up a private Nuget repository to make this easier.
If it is absolutely necessary to share files, you can use pre-build actions in your project to copy the file from a common location, or even download them from google code. It's not clean, but if you don't want to use source control for it then I don't think you will find a clean way.
I like to keep a library folder of binaries in my Dropbox. That way Common libraries that I use can be accessed from my home and work project workspaces and the service keeps the version up to date.
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.
Good day all,
I have written an application that i require to have a certain directory structure/. Nothing complex but it will need an "Images" Folder which contains two other folders "Temp" and "Complete".
These folders are in my solution however upon publishing all the folders are gone and i can not find any way in which to cause these certain folders to persist.
Will i have to write some code that checks if these exist and create them or can i make an application directory structure exist from the very beginning.
Dont know if this is relevant but i am using WPF and deploying through click-once.
Thanks,
Kohan
Regardless of whether you find a solution to the installation part of your question it would be prudent to check that the folders exist either on application start up or when you need to access them. After all, someone could come along and delete them without realising that they're needed. You might want to report or log this as an error, but recreate them anyway.
I assume you are using Visual Studio to create your ClickOnce deployments. If so, you can get around this issue by using MageUI instead.
Create your desired folder structure separate from you project's source code and bin folders. Copy in all the files you want deployed. Use MageUI and when you create the application manifest, point it to the root folder you created. It will take care of all the subfolders.
Also, I wouldn't worry too much about what ChrisF said. ClickOnce files are deployed to a very obfuscated location that users should never be in. And if they are in there deleting stuff, you'll likely have much bigger problems that a missing subfolder.