I need to store the release build of my Flash Builder (Flex) application in Subversion. When I try to add it to version control via Subclipse I get a warning telling me that I have asked to version control one or more resources that otherwise would have been ignored. Does anyone know why this is happening, and how I can get around it? I've gotten around this one time in the past by adding the build release's directory to the repository using another Subversion client, i.e. outside of Eclipse/Flash Builder, but when I rebuilt the release later I was unable to get Subclipse to see the changes between the base/head revisions and the new local versions of the build release files.
I realize that what I'm doing is non-standard and I suspect that there are default svn:ignore settings someplace which are causing this to happen, but I can't figure out where these are in order to modify/bypass them. Or maybe there's something else going on?
Thanks in advance for any insight and/or help with this issue.
This is an Eclipse-specific feature. Eclipse has a feature where files that are produced by compilers or generates inside Eclipse can be marked in Eclipse as "derived" resources. Eclipse team providers are supposed to ignore these files automatically. AFAIK, that is the only reason the feature exists.
So Subclipse still allows you to manually choose one of these files to version, but it warns you that you selected files that Eclipse said to ignore.
It is possible (but I have no idea) that Flex Builder has some setting to control whether or not it marks these files as derived.
Related
I just accidentally refactored QList to QSet, and Qt faithfully did it, to all of its own sources too... (yup, that was dumb!)
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
There's no point to using source code control for an install: it's not source code. It's artifacts. You already know how to protect artifacts of all sorts from modification. Proper filesystem attributes will do it just fine.
Your finished Qt installation should not be writable by you. It would be by default on Unix systems when installed using a privileged package manager. Elsewhere: you need to make it read only. If you build from source, then recursively making the install folder read-only as the last step after installation is all it takes; and since you should be already automating your Qt build, then adding the "make read-only" step is trivial.
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Feasible? Definitely. Sensible? Perhaps, assuming that by "make a git repo" you mean "cloning the official Qt repos from Git". It depends on how many times you plan on making the same renaming mistake. :D But seriously, I think there are benefits to building Qt yourself:
You can easily debug and check the implementation of API that you're using.
You can configure Qt to skip building stuff that you're not interested in.
You can easily patch Qt if there's a bug that you know of a fix for but hasn't been merged into Qt itself yet.
There are downsides too, though. You might run into build issues if you're using configure flags that the CI doesn't use (such as a -no-foo option). It can take a while to build depending on how many submodules you have and what kind of machine you're building on.
In general, if you're not using API that's in dev and not yet released, it's probably not worth bothering.
If you're still interested, this page has instructions for building Qt from Git:
https://wiki.qt.io/Building_Qt_5_from_Git
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
Couldn't you set some permissions on the source directory? I've never had to do this, but have been bitten by it on unrelated occasions before, so I know it works. :D
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
Remove and add is your only option, I think. Otherwise, you can always keep a backup of the source by just copying the whole directory.
I am using Spring Source Tool Suite 2.8.1 to implement Spring applications.
I frequently get build errors because references are lost for no apparent reason. In Right-click project in Package Explorer->Properties->Java Build Path->Order and Export, I find projects sometimes are deselected. And often packages are gone in Right-click project in Package Explorer->Properties->Java Build Path->Deployment Assembly.
Having to reset these settings frequently is frustrating. Is there some way I can work around these problems?
I have tried to update STS to the latest version, but the upgrade process fails with incomprehensible error messages. I want to avoid a clean install because setting up the environment again would probably be a nightmare.
Now that I know this is a maven project and you are adding references yourself, this is making sense to me. STS 2.8.x was the last STS to ship with the legacy m2e (maven plugin for Eclipse). It did not recognize build path entries added manually (it likes to have complete control over the classpath). So, what is likely happening is that you are adding these classpath entries and then an update project operation gets kicked off automatically. This will have the effect of removing all of your extra classpath entries.
You are best off doing the following:
Updgrading STS
Or just upgrading your m2e component (you will have to first uninstall the old m2e, but this should be taken care of automatically from the discovery update page).
Or, just accept the fact that you can't manually change your classpath with the legacy m2e.
Is it possible to exclude a folder in a web project from being published? We've got some documentation and scripts that included in a particular project folder, and are added to the project, but when I do a VS publish, I don't want them to go up to the production server.
I know they shouldn't be in the project, but I thought I'd find a workaround before I try to convince the owner to modify the way he's doing things.
Old question, but I found if I mark the folder as hidden in Windows Explorer, it doesn't show/publish in your solution.
This is good for example to stop original photoshop images being included in uploads which aren't used and are big. Anything more complex though you'll probably want to write your own publish tool.
This doesn't answer your question, exactly, but my feeling is that unless you are a single developer publishing to a server, you would be better off doing builds on a dedicated workstation or server using MSBuild (or some other building and deploying solution) directly (and thereby would be able to very granularly control what goes up to production). MSBuild can not only build, but using some extensions (including open source types), it can also deploy. Microsoft has a product called MSDeploy in beta, and that might be an even better choice, but having no experience with it, I cannot say for certain.
In our situation, we have a virtual workstation as a build box, and all we have to do is double click on the batch file that starts up an MSBuild project. It labels all code using VSS, gets latest version, builds the solution, and then deploys it to both servers. We deploy exactly what we want to deploy and nothing more. We're quite happy with it.
The only downside, if it could be considered a downside, is that at least one of us had to learn how to use MSBuild. VS itself uses MSBuild.
For the files you don't want to go, loop at the properties and set the 'Copy to Output Directory' to 'Do not copy'
This option is not available for directories, however.
Can you not exclude them from the project through visual studio to stop them being published. They will the still exist in the filesystem
The only way that you can do this to my knowledge would be to exclude it from the project, do the publish, then re-include it in the project. That can be an issue.
There are probably much better ways to solve this problem but when we publish a build for our dev servers, we'll run a batch file when the build is complete to remove the un-needed folders and web.configs (so we don't override the ones that are already deployed).
According to http://www.mahingupta.com/mahingupta/blog/post/2009/12/04/AspNet-website-Exclude-folder-from-compilation.aspx you can just give the folder the "hidden" attribute in windows explorer and it won't publish. I tested this and it works for me.
Seems like a straightforward solution for quick and dirty purposes, but I don't think it will carry through our version control (mercurial).
Select all the files that should not be published.
Go to Properties
Set
Build Action -> None
Have to repeat the process for each sub-directory.
Setting up Flex project for group development can be a bit tricky. There are lots of little local settings that might need to be tweaked in order to have a project that can be easily checked out.
I've had limited success using the built-in import/export flex project utilities. I seem to wind up editing by hand a lot and I think I might be missing something.
UPDATE
I neglected to mention originally that my goal is to make it possible to checkout a project from subversion and get up and running with as little fuss as possible. The biggest problems that I have run into all revolve around managing the "dot" files and how to make them flexible enough to deal with different developer environments.
For example, even with just me, I would like to have this ability: at work, I use a Vista machine and at home I use a Mac. There are certainly differences in the way certain paths are described, but they really are quite similar. On Vista, the flex root is c:/ColdFusion8/wwwroot, on OS X, it is /Applications/ColdFusion8. I have been able to set up a linked resource path variable for both CF_FLEX_SERVER and WEBSERVER that I then reference using the ${WEBSERVER}/myProject syntax.
So far, it seems to work pretty well, but I find there are a few places that it still has issues. Specifically, in the .project file you find something like:
<linkedResources>
<link>
<name>bin-debug</name>
<type>2</type>
<location>c:/inetpub/wwwroot/myProject-debug</location>
</link>
</linkedResources>
Unfortunately, if I try to change the location entity to ${WEBSERVER}/wwwroot/myProject-debug, flex throws a compiler error. That's a shame, because pretty much everything else works.
I have worked through this problem before and generally set my projects up as such:
Application/trunk/source/ <-- workspace is here (can also be in 'trunk')
Application/trunk/source/Application <-- Application here
I DO keep my project (.actionScriptProperties, .flexProperties, .project, .settings) in SVN, but NOT my workspace (.metadata) because it's too big.
I find that importing projects via Import -> Flex Project enforces alot of restrictions. For example, if your workspace was in the 'trunk' directory above then importing as a Flex Project will cause the project to be copies into trunk/Application or simply complain about the location.
The better way to go about it is to create the workspace and then Import -> [General] Existing Projects into Workspace. The only difference is that you will have to manually add the Flex Development perspective.
Edit: I'd also recommend setting your compiler options to "Use default SDK" and then setting the appropriate SDK as default. This will prevent commit-tennis when each developer names his SDK differently.
Since Flex Builder is written on top of Eclipse, it can integrate with Subclipse. This allows you to pretty easily tag files as 'SVN ignore' to avoid project-specific settings. I've used this to add my Flex projects to an existing SVN repository, which I've checked out to multiple sites. I have noticed a few issues here and there (some checkins get errors, but they're relatively rare), but it generally works.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.