So in my company we have this huge website project in Visual Basic. On this problem we have two parts involved, the admin, running at one port in local, and the website, running on another port.
The problem I have is that when I change a user's property in admin, it calls the function to save the user and adds the changes to the database. After that, we run a HttpRuntime.Cache.Remove(key) and it is removed successfully. BUT when the website part tries to get the user from cache (before doing so from the database), it gets it successfully, even though it was removed previously. So my question is if this is a thing, if it's possible that even though using the same code, there are 2 different caches, I've done several tests and the cache is removed successfully from the admin part, it's definetly not a code problem.
So apparently, that's how it works. If the same project has 2 or more applications running at the same time, each one has its own cache, even if they share the code that removes or adds things to cache. There is no mistake, the answer would be to create a function that clears the cache from the other applications.
Related
I used to work on the live website when I'm editing a website (I'm working alone), but some people told me "it's the old way". I'm inclined to evolve and I like to work, but how can't I lose time doing this?
First, that means that I need to get a copy of the website on my computer. I need to copy the files, dump and restore the database, first waste of time. If my customer adds extension on the website in the meantime(for example, Wordpress) my modification should be impacted then I need to add it on my local copy to. If I need to modify the DB I will need to do it on the local copy too.
Secondly if I want to show a work in progress to my customer I need to apply all modifications to the live website and check than everything works, still a waste of time.
And finally when everything is ok, I need to update again the live website, files and DB.
So, there's two options:
this is not the correct way to do and there's tools to do all that transparently (I hope so)
this is not a waste of time but a needed time to work properly (I understand why agency have big prices and I'll keep my method)
It depends on the complexity of the project and the size of your team.
One of the major risk of working on a live site is the introduction bugs in production. You also want to have some confirmation of functionalities developed from QA or your customer before having your users access them.
Basically, you want to make sure your new code does not break the live site, so working on the local instance could help you in this way, and you could also deploy on the live test site you changes for approval and QA.
Also if you working with a larger team working on the live site just won't scale up and the risk of introducing bug is even higher.
You could consider using docker, to simplify development on your local machine.
I created a time recording program in vb.net with a sql-server as backend. User can send there time entries into the database (i used typed datasets functionality) and send different queries to get overviews over there working time.
My plan was to put that exe in a folder in our network and let the user make a link on their desktops. Every user writes into the same table but can only see his own entries so there is no possibility that two user manipulate the same dataset.
During my research i found a warning that "write contentions between the different users" can be occur. Is that so in my case?
Has anyone experience with "many user using the same exe" and where that is using datasets and could give me an advice whether it is working or what i should do instead?
SQL Server will handle all of your multi-user DB access concerns.
Multiple users accessing the same exe from a network location can work but it's kind of a hack. Let's say you wanted to update that exe with a few bug fixes. You would have to ensure that all users close the application before you could release the update. To answer you question though, the application will be isolated to each user running it. You won't have any contention issues when it comes to CRUD operations on the database due to the network deployment.
You might consider something other than a copy/paste style publishing of your application. Visual Studio has a few simple tools you can use to publish your application to a central location using ClickOnce deployment.
http://msdn.microsoft.com/en-us/library/31kztyey(v=vs.110).aspx
My solution was to add a simple shutdown-timer in the form, which alerts users to saving their data before the program close att 4 AM.
If i need to upgrade, i just replace the .exe on the network.
Ugly and dirty, yes... but worked like a charm for the past 2 years.
good luck!
I am trying to get this IndexedDB stuff working in a Metro (Windows 8) app, using JS.
I thought I was good, but then I ran the WACK tool a couple of times, just to see if I ran into any issues.
After these tests the IndexedDB.open call no longer opens my database (which has 7 entries in it) instead it fires onupgradeneeded, and gives me a blank (new) database (since I create an object store in the onupgradeneeded handler).
I did not change my version number, I did not change the database name. So I am guessing the applications domain somehow changed during the WACK tests.
Does anyone now how to get my database domain back?
One of the things the WACK test probably does is doing a fresh install of the app checking if everything goes fine. So when the app is installed for the first time you have to provide a creation of the database, this is done in the onupgradeneeded event.
I think you forgot to provide this, and that is why he creates a new blank database. Instead of a new database with the required structure.
I'm working on creating a self updating application and one issue I'm running into on Vista and Windows 7 is needing to have admin privileges in order to update the client. I've run into issues with clients that have their users running under restricted permissions and they would have to have IT log onto every machine that needed to update the client since the users were not able to.
A possible work around I'm considering is to have the launcher application installed into Program Files as normal, and having the real application that it updates installed in the users documents somewhere, so that they could update and run new versions without IT becoming involved.
I'm wondering what potential gotchas I'm missing here or what I should be aware of before heading down this path. I'm aware that click-once does something very similar, and I'd be using it, except I need the ability to do silent updates, without any user interaction.
This is how it is supposed to be. The last thing most IT departments want is a user randomly updating a piece of software. This could have all sorts of unintentional side effects such as incompatibility with the older version's files, new and possibly insecure functionality, etc. This is why IT departments disable Windows Update and do their updates manually in a controlled fashion.
If the users want an updated version of the software they should be requesting it from their IT department. Those computers and infrastructure don't belong to them, they're simply borrowing time on them from the company they work for so they can do their job.
Is there an issue with having only one installation of your program? Is it particularly large, for example?
Do you require admin privileges to run your program?
If not, odds are you don't need the Program Files folder.
I suggest you forgo installing to Program Files entirely and just install your program into the user's folder system at <userfolder>\AppData\ProgramName.
If you happen to be using .NET, look into the ClickOnce deployment mechanism. It's got a great self-updating feature that'd probably make your life a lot easier.
Edit: Just saw your last sentence. ClickOnce can force the user to update.
A couple of things:
If you decide to move your app to some place in documents, make sure that your application writes data transparently to where your program is installed, e.g. if there are hard coded paths anywhere in the code that are pointing to bad places. Perhaps this is not an issue for you, but might be something to keep in mind.
We solved this in pretty much the same way when we decided to implement a "live update" feature. But instead we installed a service which is running with administrator rights. This service in turn can run installers once the program needs to be updated. With this type of solution you don't even have to move your applicaton out of program files.
Cheers !
Edit:
Another neat thing with having a service running as administrator. Is that you could create a named pipe communication with it and have it do things for you, like you wouldn't be able to do as a normal user.
A loader stub is a good way to go. The only gotcha is when you have to update the loader; the same initial problem applies (though that should be pretty infrequent).
One problem that I can think of off the top of my head is that you're stepping outside the entire idea of keeping things more "secure." Since your executable exists in a location that should be completely accessible to a non-administrator, it's possible that something else could slam your exe thus subverting security.
You can probably leverage AppLocker. It may only be for Win7 though I'm not running Vista any more. ;)
I just executed installutil on a DLL in which custom performance counters are installed. I installed 2 categories but then realized I had an issue with the first category, so I deleted the category but before deleting I ran an asp.net app against to make sure it was working.
The issue is after deleting the category and then recreating the application is logging to the custom perfmon counter but the values never get updated.
The second custom category works fine and counter is getting populated. I can see both categories within perfmon but noticed that the first category counters never get updated when running an asp.net against it.
Has anyone run into this issue. Do I need to delete the existing instance? I'm trying to avoid a reboot of the machine.
depending on how you install the counter, (assuming transacted installation let's say...) perf counters can get "orphaned".
IMHO this is because perf counters seem to get installed in the Reg and "elsewhere" <--still trying to find out where else perf counter info gets stored.
In some cases, the regkeys get built appropriately and so register as appropriate but the OS "elsewhere" location is not properly built out. It's almost like there is a perfcounter cache somewhere. ( comments anyone?)
So in summary after installation run lodctr /R from the commandline with the appropriate perms and this "seems" to solve the issue for most installations. I would be interested to see what others say about this as the generally available documentation (i.e. MS) SUCKS beyond belief on this topic...
grrr.