This morning my boss asked me if I was making changes in the Domino PNAB. I wasn't. I did make one change the day before. Well Designer is showing that I signed scores or hundreds of design elements in the address book, which I did NOT do, at least manually.
We have seen this on and off for years now, and always just ignored it (my boss would resign the design.
Has anyone else experienced this or know what could be the cause. I think I will probably have to open an PMR with IBM.
There could be a few causes. Ones that come to mind are design refresh occurring, auto-refresh from source control ODP and replication from another source. The User Detail on the database may be informative (Database Properties, second tab, User Detail...), it may show when it occurred, which could clarify things.
If you have Build Automatically enabled (I don't), that could cause issues with signing, especially if any change is detected by different signers. Notes/Designer 8.5.3 IF2 should fix an issue where just opening an NSF can causing a signing change for Java classes, but that should be fixed. As Paul mentions, watching out for any potential changes to an app, such as automatic import from ODP, etc., should be watched for. I'm rather leery of leaving Build Automatically on or anything making a change without my explicit direction. I mention this since my company still has a surprising number of older client versions.
Kathy Brown's blog post on the subject ca. pre- 8.5.3 IF2:
http://www.runningnotes.net/index.php/2013/08/29/mystery-application-breakage/
Related
In a rather complex project the entire project team is encountering more and more problems regarding designer, like frequent crashes, exceeding of memory limits and- most annoying - problems with outdated project data:
quite often we observe that two different designer clients are showing different versions of project data (see below for a rough description of the environment).
A simple example: an hour ago a co-worker asked me to open and test a new Xpage she had created 15 minutes ago in her Designer. In my Designer client however the new Xpage was not present yet. right-clicking my application and hitting "refresh" brought up the new Xpage.
The problem hits the ceiling with design elements that we both are working on in turns (as in "are you currently working on xpage XXX? I'd like to add..."). So with this syncing delay the problem is obvious: If I foirget to manually sync my project before adding stuff I will overwrite the co-workers' codings.
We never had this problem before, although I have to admit that we never had to work in a team on such a massive project.
Here's the setup:
all designer clients are 9.0.1 FP6
everyone is working on the same project stored on the same server
everyone is working on the same network withion the same building, just door-to-door
Is there something we could do or check to improve this situation?
Lothar, you have stated three problems at once. I'll try dissect them.
Frequent crashes:
We experienced many, many crashes in our daily work after upgrading to Windows 10. I know it sounds silly, but one way it worked for us and successfully mitigated those crashes was installing IBM Designer into C:\IBM\Notes, instead of C:\Program Files\IBM\Notes.
Granting 'Full Access' to 'All Users' over that folder was also necessary.
Exceeding of memory limits: As jtomas correctly pointed out, default memory settings are not enough for heavy xpages development in Domino Designer. I would suggest going to vmarg.Xmx=-Xmx1024m.
Problems with outdated project data: I think there is no workaround for this problem because there is no problem. Domino Designer 9 is a Eclipse based software, and works like so.
Think about it: When working in Java projects, developers download (checkout) source files from a Source Control System (SVN, Git, etc) and work them locally. Whenever a developer modifies or create a file, another developer can see it only if:
a) The modified/new file has been uploaded (commit) to Source Control Repository; and
b) Other developers have synchronized (refresh) their local projects with the repository.
See, that's how Java development works and that's the way we should do it too. Upon opening a NSF file, Domino Designer breaks it down into many files, just like a Java project. Once locally saved into the Java Virtual File System, those files get updates only when you refresh the project. Silly, but it is what it is.
My recipe to a well succeeded Domino development team include:
1) Design locking: All developers must explicitly lock elements they will work on. We don't rely on implicit locks.
2) Communications: All members of the team must be immediately notified whenever a developer has made major updates to the project.
3) Source Control: Despite its pitfalls, we rely heavily on SVN as code repository. It's far from perfect, and merges don't work properly, but it's better than no control.
Hope it helps.
I'm not sure this will fix your syncing issue but I have found modifying the following 3 lines in your local Notes\framework\rcp\deploy\jvm.properties file to help with Designer performance when developing in XPages especially with large projects:
vmarg.Xmx=-Xmx512m
vmarg.Xms=-Xms48m
vmarg.Xmca=-Xmca512k
These are the memory limits I use. You can increase the limits just make sure they are a multiple of 4. You have to restart Notes & Designer for changes to take effect.
I am facing a huge problem with Sharepoint Online. We have two sites and both of them have the same solution deployed. Both solution are subsites and have their features at web scope.
The solution has a main list that we put some data in it depending on some rules but as it is not part of the main issues this is not important.
The problem is that recently something really annoying is happening in these environments. This main list, usually during the week and during the morning is being deleted, and also the features of the solution are being deactivated.
The team came up with some ideias about what is happening:
Some code in the solution that delete the main list.
Someone is deleting the main list (someone really bad).
List is being deleted by a sharepoint job.
To configure the main site is affecting the subsites and causes the deletion of the list.
I think that options 1,2 it are not happening.
Everything would be resolved if we have access to central administration or even to some log, but for security reasons we don't have access to them, what is really bad for us, as developers because we have to guess what is going on.
Can someone give some tips about how to identify this problem?
Please let me know about any more important additional information that I havent written so far.
Thanks in advance!
Indeed not being able to read logs is very inconvenient.
Also, in CSOM, property AllowDeletion for List isn't exposed; as it is for SSOM instead.
The only way I'm thinking you have to intercept when this happens, is to create a custom Remote Event Receivers, which hooks ListDeleting / ListDeleted events
This should be a rather up-to-date and good start if you're new to RERs
https://msdn.microsoft.com/en-us/library/office/jj220048.aspx#RER
I am a new developer (as in just graduated on the 10th) and was hired by a company to do web development. I was asked to do some minor changes to a site that this company acquired. The problem is that we do not have access to the source code (apparently the people had a bad break up with their previous developers and cannot get the source, I'm not exactly sure). Is there a way I can add links to a site and have it change live? I have Visual Studios, the address, the links, and the videos they will go to, not a hard fix, but I don't know how to edit the site without the source code. Any suggestions? Thanks in advance!
I advise you to talk to a senior or superior and get more information on how to proceed, because getting that code in a less than professional (or legal) way (e.g. using website rippers or something) would be a bad career move ;)
good luck.
interesting situation I should say, the company definetely didnt do its homework before the break-up
I am presuming you answer "yes" for the questions below
Is your company the legal owner of this website?
can you change the name servers or CNames etc
The current website is not Flash or silverlight
if here - you have said "yes" for all the above.
First of all navigate to every page of this website. File save as
each of this page to html(make sure you choose webpage complete -
this will save all the images as well) I realise this will be static, but there is not much you can do here
Get all resources (stylesheets, xsds (if any) , any other images)
Enrich this content based on requirements (i.e. add dynamic content, change logos etc)
Modify the cname or nameserver to point to the location(webserver)
you are in control.
Deploy your enriched and tested code
Educate your company to treat the developers well and when things go wrong, ensure transition is done well
I hope this help and good luck
Krishna
Is there a way to determine what features are actually being used by the site.
Not activated, but actually being used.
IE. FeatureA is used in /SiteA or /SiteB/Lists/ListA
I know what features are activated and have tool from codeplex to extract the deployed features as a .wsp file.
I want to cleanup the server and generate a development box from production. Last SP admin used the production server as his play area and installed a ton of features which are not used.
Would this data be available through the SharePoint Object Model, database, or some obscure area of the site setting pages?
Thanks
The short answer is no. The long answer - it really depends on the nature of the feature. Some features, such as those that add items to the menus/ribbons, are "used" only when the button is actually clicked, so the question is pretty meaningless here. If someone uses the feature button from time to time, you have no way of knowing, unless you are willing to ask everyone what they are using.
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.