I was wondering if someone could help me sort this out.
Hotfix vs Patch vs Update.
I have look around the website but it only mentions about programs.
From what I understood,
Hotfix is to fix a certain bug and not always will be public announcement.
Patch is fixing few bugs and its public announcement.
Update is adding new content (as well as fixing bugs)
but isnt Patch used for new content as well?
I'm a bit confused with those terms
HotFix come in the form of a configuration change to workaround a problem or to fix a running application or server with minimal down time.
Patch is typically an update to existing code and delivered in binary form to fix a specific issue, bug or compatibility problems.
Updates can be used for enhancement or to bring an application up to date (and possibly contain multiple fixes rolled up).
Related
My company recently migrated to Visual Studio 2012 and I am using it to develop web application using ASPX pages. The pages are split with the C# in a code-behind file. After using 2012 for a couple weeks now, I noticed something: if my ASPX page does not correctly validate to the HTML5 standard (i.e. I am missing a closing tag somewhere), the page will not save. This problem does not occur in the code-behind file, nor does it occur on Razor pages.
I briefly looked through the standard Visual Studio settings pages, but cannot find a setting to allow invalid code to be saved. I also have Resharper installed (as well as the Productivity Power Tools), but cannot find a setting in either of those extensions that seem to relate to my issue. If it matters, the project I am working on is part of a TFS solution.
Has anyone else experienced this issue? If so, does anyone know of a setting that might have caused this that I may be overlooking?
Update: Since posting this, I have noticed that I am unable to save even after the page has been validated. It can take up to a minute before Visual Studio allows me to save the page. The length of time may be related to the amount of text that I entered before trying to save.
Update 2: After talking to a coworker who has a similar set of extensions, I determined that Resharper must be causing the problem. If anyone knows of a Resharper 7 setting that may be causing this, please let me know. I can't tell if this is a bug or an intended feature.
Final Update: Thank you to all who offered assistance, but after installing the Visual Studio Update 1, I no longer notice the problem. It seems to have been a bug that was fixed with the update.
As stated in the final update section in the question, after installing the Visual Studio Update 1, I no longer notice the problem. It seems to have been a bug that was fixed with the update. Problem resolved!
Grrr, still happening in 2015, and I don't even have ReSharper or Productivity Power Tools installed. I found a workaround. I quit VS, said YES to saving the items in the popup, reopened it, and found that they were saved to older statuses. I re-changed the code, saved (took many seconds but probably less than a minute), and recompiled, and the changes took this time.
It was nice that when I quit and saved (unsuccessfully), it at least showed that the code was in an older state, instead of showing the newer code with a perpetual asterisk.
I'd never seen this before, and hope never to again.
I've been recently tasked with leading an effort to improve our input (and output) validation with OWASP recommendations and PCI compliance in mind. In the process, I'm trying to assess the value of the ESAPI.NET project which does not appear to have seen any activity since the spring of '09 and as it stands is incomplete.
Does anyone have experience using or extending ESAPI.NET v0.2? Is it a good starting place today for building out an infrastructure to address the targeted vulnerabilities?
FYI: I am looking at MS AntiXSS which, of course, only addresses a portion of ESAPI's scope. We already do a good job with SQL injection though there are improvements we need to make.
(If someone wants to create an ESAPI tag, feel free. I don't have the mojo.)
Looks like there were a couple updates last week: http://code.google.com/p/owasp-esapi-dotnet/source/list
You might contact one of the project leads on that list to ask what's going on.
NOTE: 05/26/2012: the last update on that project was dec 4, 2010. Yes, it is dead.
It looks like ESAPI is dead period. There's nobody using it, there are no questions, no forums, no information, nothing. The listservs (what is this, 1996?) are barren too. The documentation is terrible and the samples in the swingset don't work (server that installs is HTTP not HTTPS, and no transactions can be made in HTTP mode).
Seems to be a dead end project.
The project itself seems dead there are however some people who maintain a github copy with several (minor?) additions...
https://github.com/haldiggs/owasp-esapi-dotnet
https://github.com/jstemerdink/owasp-esapi-dotnet
I did several websites with Drupal, and now the core is updated and I cannot come back to my customers to update previous installation. I was wondering how risky is to not update drupal core to the last version and how web developers should deal with websites management.
ps. My customers do not have any computer skills.
thanks
The openness of open source means that it is easy to know what an upgrade has fixed. It also means that a hacker could just look at the release notes and do a diff between the previous and current version to spot the vulnerabilities in the previous version.
If you have a good relationship with your clients I would explain the need for an upgrade and see if they want to pay you for it, as their sites are vulnerable to anyone determined enough to look at the release notes and do a little digging.
Here are release notes. Answer on your question lies inside.
Updating the core is very Important, it solves some security risks and brings new features.
We have 4 different environments:
Staging
Dev
User Acceptance
Live
We use TFS, pull down the latest code and code away.
When they finish a feature, the developers individually upload their changes to Staging. If the site is stable (determined by really loose testing), we upload changes to Dev, then UserAcceptance and then live.
We are not using builds/tags in our source control at all.
What should I tell management? They don't seem to think there is an issue as far as I can tell.
If it would be good for you, you could become the Continuous Integration champion of your company. You could do some research on a good process for CI with TFS, write up a proposed solution, evangelize it to your fellow developers and direct managers, revise it with their input and pitch it to management. Or you could just sit there and do nothing.
I've been in management for a long time. I always appreciate someone who identifies an issue and proposes a well thought-out solution.
Whose management? And how far removed are they from you?
I.e. If you are just a pleb developer and your managers are the senior developers then find another job. If you are a Senior developer and your managers are the CIO types, i.e. actually running the business... then it is your job to change it.
Tell them that if you were using a key feature of very expensive software they spent a lot of money on, it would be trivial to tell what code got pushed out when. That would mean in the event of a subtle bug getting introduced that gets passed user acceptance testing, it would be a matter of diffing the two versions to figure out what changed.
One of the most important parts of using TAGS is so you can rollback to a specific point in time. Think of it as an image backup. If something bad gets deployed you can safely assume you can "roll" back to a previous working version.
Also, developers can quickly grab a TAG (dev, prod or whatever) and deploy to their development PC...a feature I use all the time to debug production problems.
So you need someone to tell the other developers that they must label their code every time a build is done and increment a version counter. Why can't you do that?
You also need to tell management that you believe the level of testing done is not sufficient. This is not a unique problem for an organisation and they'll probably say they already know. No harm in mentioning it though rather than waiting for a major problem to arrive.
As far as individuals doing builds or automated build processes this depends on whether you really need this based on how many developers there are and how often you do builds.
What is the problem? As you said, you can't tell if management see the problem. Perhaps they don't! Tell them what you see as the current problem and what you would recommend to fix the problem. The problem has to of the nature of "our current process has failed 3 out of 10 times and implementing this new process would reduce those failures to 1 out of 10 times".
Management needs to see improvements in terms of: reduced costs, icreased profits, reduced time, reduced use of resources. "Because it's widely used best practice" isn't going to be enough. Neither is, "because it makes my job easier".
Management often isn't aware of a problem because everyone is too afraid to say anything or assumes they can't possibly fail to see the problem. But your world is a different world than theirs.
I see at least two big problems:
1) Developers loading changes up themselves. All changes should come from source control. Do you encounter times where someone made a change that went to production but never got into source control and then was accidentally removed on the next deploy? How much time (money) was spent trying to figure out what went wrong there?
2) Lack of a clear promotion model. It seems like you guys are moving changes between environments rather than "builds". The key distinction is that if two changes work great in UAT because of how they interact, if only one change is promoted to production it could break there. Promoting consistent code - whether by labeling it or by just zipping up the whole web application and promoting the zip file - should cause fewer problems.
I work on the continuous integration and deployment solution, AnthillPro. How we address this with TFS is to retrieve the new code from TFS based on a date-time stamp (of when someone pressed the "Deliver to Stage" button).
This gives you most (all?) the traceability you would have of using tags, without actually having to go around tagging things. The system just records the time stamp, and every push of the code through the testing environments is tied to a known snapshot of code. We also have customers who lay down tags as part of the build process. As the first poster mentioned - CI is a good thing - less work, more traceability.
If you already have TFS, then you are almost there.
The place I'm at was using TFS for source control only. We have a similar setup with Dev/Stage/Prod. I took it upon myself to get a build server installed. Once that was done I added in the ability to auto deploy to dev for one of my projects and told a couple of the other guys about it. Initially the reception was luke warm.
Later I added TFS Deployer to the mix and have it set to auto deploy the good dev build to stage.
During this time the main group of developers were constantly fighting the "Did you get latest before deploying to Stage or Production?" questions; my stuff was working without a hitch. Believe me, management and the other devs noticed.
Now (6 months into it), we have a written rule that you aren't even allowed to use the Publish command in visual studio. EVERYTHING goes through the CI build and deployments. When moving to prod, our production group pulls the appropriate copy off of the build server. I even trained our QA group on how to do web testing and we're slowly integrating automated tests into the whole shebang.
The point of this ramble is that it took awhile. But more importantly it only happened because I was willing to just run with it and show results.
I suggest you do the same. Start using it, then show the benefits to get everyone else on board.
Anyone else using this? I've just installed it, documentation is hidden somewhere, and so far it's not doing to well. It's Toolbox tab is missing, and when I add the items manually, they disappear again seconds later. I have managed to get one report done, but nowhere can I find how to make the viewer show it, without a very long winded error about not finding a certain path.
As Mark and Martin already pointed out Telerik support is second to none, so you would surely get help in their forums/support threads. I'm currently working with their Reporting product and honestly I have not experienced any problems so far. I've read that they had problems with the toolbox in x64 bit machines, but it has been resolved in the latest service pack, so you might want to make sure you are using the latest version first. However adding the items manually to the toolbox would definitely work and if you are having problem with that too, it sounds more like a Visual Studio problem to me. Also looking at their system requirements, VS Express editions are not supported, so this might be the case as well.
Looking through their help, I find a whole section about their reportviewer and how to use it - check it out: http://www.telerik.com/help/reporting/aspnetreportviewerembedding.html
You can find the complete documentation and tutorials online in the support section of their site. If this does not help, ask in the forums. And since you have valid license, you can also create a support ticket.
I can't comment on the reporting component, since I have never used it. But I do use the ASP.NET controls and from that I can tell you that you will usually get help very quickly (especially when creating a support ticket).
Telerik offers many useful controls and is generally quite conscientious about their code and support. You're likely to have more luck on their site's forums.
With that being said, I found their reporting tool to be quite buggy and unusable.